Protocole HTTP : la pratique

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Voici la deuxième partie de l’article sur le protocole HTTP. Ici, nous nous intéresserons à la partie pratique. En utilisant des add-on tels que Tamper Data ou encore l’outil BurpSuite, nous pouvons modifier le contenu des headers. Si la plupart du temps cela va juste rendre le paquet inutilisable, il peut arriver que cela amène à des situations inattendues.

I/Redirection 302 -> 200

Eh si je vous disais qu’il est possible de bypass certains mécanismes de protection juste en modifiant trois chiffres? Eh bien sachez que c’est possible. Pour cela nous allons exploiter la redirection 302 -> 200.

Ces deux valeurs sont des codes de statut. 302 pour redirection et 200 pour succès.

Prenons un exemple. Nous avons un site web avec un répertoire /admin qui n’est accessible que si je suis connecté en tant qu’admin. Si je me connecte en tant qu’admin et que je me rends sur ce répertoire, je vais recevoir une réponse du serveur dont le code de statut sera 200 et j’aurais donc accès au contenu du répertoire. En revanche si je ne suis pas connecté eh bien je vais recevoir une réponse dont le code de statut sera 302 et je serais redirigé vers une page sur laquelle j’ai les droits d’accès.

Maintenant que se passerait-il si je modifiais le code de statut 302 en 200 dans le header de la réponse du serveur? Eh bien il se pourrait que j’ai accès, sans être authentifié, au répertoire /admin !

Pour illustrer cet exemple, je vais me servir du site webscantest ainsi que de l’outil BurpSuite.

Webscantest est un site dont je me suis déjà servi pour l’article sur l’espionnage réseau 1, il permet de simuler des attaques telles que les CSRF, les injections SQL et bien d’autres. Dans notre cas nous allons nous servir de la page d’authentification.

Quant à BurpSuite, c’est un outil très complet qui a de nombreuses fonctions : proxy, scanner,  décodeur, comparateur de code… Ici nous allons nous servir du proxy afin d’intercepter la requête HTTP sortante (de notre machine) et entrante (venant du serveur).

Voici la page d’authentification que nous allons utiliser :

accueil

Si j’essaye de rentrer des identifiants au hasard, je vais recevoir ce message :

mauvais

Maintenant nous allons aller sur BurpSuite. Sur Linux, ouvrez un terminal et tapez « burpsuite ». Créez votre projet puis appuyez sur « commencer ». Voila ce que vous allez obtenir :

burpaccueil

Allez dans l’onglet « Proxy » et cliquer sur « intercept on ». Maintenant allez sur firefox, dans l’onglet « préférences » puis « avancés » et « réseau ». Cliquer sur « paramètres ».

advanced

Une fenêtre va s’ouvrir vous demandant si vous voulez configurer un proxy. Remplissez les champs de cette manière :

configproxy

Voila, votre proxy est prêt. Retournons sur le site webscantest. Entrez des identifiants invalides puis cliquez sur login. Aller sur BurpSuite et voici la requête HTTP :

requetefirst

On retrouve la méthode, la page demandée, les informations du header ainsi que le contenu de la requête (le login et le mot de passe).

Ça c’est la requête que l’on envoie au serveur. On peut donc modifier toutes les informations envoyées. Dans le cadre de la faille upload on peut par exemple modifier le type MIME (CF la faille upload).

Nous ce qui nous intéresse c’est la réponse du serveur. Pour intercepter la réponse, il va falloir cliquer sur « action » puis sur « intercepter » et enfin sur « réponse à cette requête ». Puis envoyer la requête.

Vous allez recevoir la réponse :

res

Ici il est intéressant de remarquer que l’on récupère effectivement le code de statut 302. Si on décide d’envoyer cette requête sans la modifier alors on va récupérer le message d’erreur.

Alors que si on change le code de statut par 200 et qu’on envoie la requête :

res

On atterrit sur une nouvelle page. On vient donc assez facilement de bypass le formulaire d’authentification. Il est intéressant ici de remarquer que le contenu de la page correspond au contenu que nous avons sur BurpSuite. Les deux phrases sont identiques et pour cause, ce sont les mêmes.

Maintenant imaginez qu’à la place de cette phrase on ait une page dont le contenu est supposé protégé ? Eh bien du coup on y aura accès alors que l’on ne s’est même pas authentifié !

II/HTTP Verb Tampering

Pour ce second vecteur d’attaque nous allons nous attaquer aux méthodes d’accès des données (ok je ne vous cache pas que je ne sais pas trop comment on appelle ces méthodes mais bon osef 😀 ).

Donc vous connaissez GET et POST qui permettent d’envoyer des données. Seulement ce ne sont pas les seuls méthodes d’envoi de données. Voici les autres : « OPTIONS », « HEAD », « PUT », « DELETE », « TRACE », « CONNECT ». Il est intéressant de remarquer que suivant la méthode utilisée, les serveurs réagissent différemment.

Pour cette attaque nous allons simplement modifié la méthode d’envoi de données dans le header de notre requête HTTP. Pour cela nous allons nous servir encore une fois de BurpSuite et d’une page au hasard sur webscantest.

Ici, vous avez juste à capturer la requête sur le proxy et à modifier le GET/POST en DELETE, TRACE etc…

J’ai testé l’ensemble de ces méthodes, sur quatre d’entre elles j’ai été redirigé vers une page random. Sur une on m’a dit que je n’avais pas le droit d’utiliser cette méthode et pour la dernière le serveur n’a pas compris ma requête. Bon c’était pas très concluant mais parfois ça peut donner des renseignements assez intéressants !

III/Modification du user agent

Ici nous n’allons pas procéder à une attaque. Nous allons juste tenter de nous anonymiser sur le web. En effet lorsque vous accédez à un serveur, vous envoyez votre user agent. Le user agent définit quel navigateur vous utilisez. Voici par exemple mon user agent sous mozilla (windows) :

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

A quoi ça sert de le changer? Eh bien ça peut vous être utile si un site web interdit l’accès à certains navigateurs par exemple.

Pour le changer vous avez plusieurs méthodes. Soit vous le changez directement dans le header de la requête. Soit vous utilisez l’outil de développeur de firefox.

Appuyez sur les touches Ctrl + shift +i.  Sur la droite vous aurez ceci :  user

Cliquez sur le bouton en forme de smartphone (tout à droite). Puis en haut vous aurez la possibilité de changer votre user agent. Voici une liste des différents user agent.


Voila quelques vecteurs d’attaque possibles. Il est vraiment important de vérifier les headers reçus, en fonction de leurs contenus on peut récolter des informations précieuses.

Un commentaire

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s