HTTP parameter pollution ou WAF bypass technique

Description

Certains systêmes n’ont pas d’api accessible directement via internet. Cette attque survient quand les sites prennents les paramètres envoyés par l’utilisateur sans encodé les données de manière adéquates vers l’API.

Ce qui peut permettre à un attaquant d’injecter ces paramètres pour par exemple :

1. Ecrire par dessus des paramètres
2. Modifier le comportement de l'application
3. Accéder à des données non autorisées

Vous pouvez tester n’importe quelle entrée utilisateur pour tout type de pollution de paramètre. Par exemple, les paramètres de requête, les champs de formulaire, les en-têtes et les paramètres du chemin d’accès à l’URL peuvent tous être vulnérables.

Comment faire ?

Pour tester l’attaque, placez des caractères de syntaxe de requête tels que #, & et = dans votre entrée et observez la réponse de l’application.

Considérons une app vulnérable qui vous permettent d’afficher les informations des utilisateurs en se basant sur leur username.

GET /userSearch?name=peter&back=/home

Pour accéder à ces informations le serveur va faire un call à l’API :

GET /users/search?name=peter&publicProfile=true

le

On peut donc essayer de tronquer la requête en rajoutant un # à la fin comme ceci :

GET /userSearch?name=peter%23foo&back=/home

à noté qu’il faut utilisé la version URL-encode pour encodé le # sinon la requête ne va pas être transmise à l’API.

Le frontend va donc essayer de faire cette requête à l’api

GET /users/search?name=peter%23foo&publicProfile=true

Si l’application retourne le user peter alors l’attque à peut être réussie à contrario de si elle renvoie Invalid name, cela veut dire que le foo a été interprété comme faisant partie du username.

Si l’attaque a fonctionné, il est donc possible de bypass le publicProfile afin qu’il soit supprimer de la requête du serveur vers l’api et donc de pouvoir accéder à des profils normalements inaccessible.

le &

Premier test

On peut aussi tenter d’utiliser le char & afin d’ajouter un autre paramètre entre le serveur et son API.
On utilise la version URL-encoded de & soit %26

GET /userSearch?name=peter%26foo=xyz&back=/home

Ce qui envoie à l’API :

GET /users/search?name=peter&foo=xyz&publicProfile=true

Si l’application renvoie la même réponse cela veut peut être dire que la paramètre a bien été passé mais ignoré.
#### Envoyer un paramètre invalide
Si par exemple l’on a repéré un paramètre mail :

GET /userSearch?name=peter%26mail=foo&back=/home

Le serveur enverra le paramètre modifié à l’api :

GET /users/search?name=peter&email=foo&publicProfile=true

Il faudra alors examiner la réponse afin de voir ce que l’on peut en tirer.

Réécrire sur un paramètre

On peut essayer de réécrire sur un paramètre déjà connu comme ceci :

GET /userSearch?name=peter%26name=carlos&back=/home

Le serveur envoie donc à l’api :

GET /users/search?name=peter&name=carlos&publicProfile=true

L’API reçoit donc deux nom comme paramètres. Cette attaque peut varier selon le type de technologie utilisée.

Par exemple :

• PHP - n'utilise que le dernier paramètre donc carlos
• ASP.NET - combine les deux peter,carlos ce qui peut retourner un message d'erreur Invalid Username
• Node.js/express - ne prend que le premier paramètre peter donc pas de changement de résultat

Si l’on peut réécrire sur le paramètre, il sera donc possible d’accéder à un compte administrator.