Pourquoi ai-je besoin de deux paramètres dans une attaque de pollution de paramètres HTTP?
Je lis sur la pollution des paramètres HTTP et je suis confus à propos d'une chose. S'il y a un point final comme celui-ci,
https://security.stackexchange.com/editpost/?postuid=19348
et vous avez essayé une attaque HPP, qui ressemblait à
https://security.stackexchange.com/editpost/?postuid=19348&postuid=1
Le backend n'essaierait-il pas toujours de vérifier que c'est le message de votre utilisateur que vous essayez de modifier? grâce aux cookies que vous envoyez avec la demande
Pourquoi cela pourrait-il fonctionner,
https://security.stackexchange.com/editpost/?postuid=19348&postuid=1
et pourquoi ne pouvez-vous pas simplement modifier l'URL comme ceci?
https://security.stackexchange.com/editpost/?postuid=1
L'idée serait que différentes parties du code serveur interprètent la demande de différentes manières, ce qui donne une application vulnérable à la pollution des paramètres HTTP.
Pour votre exemple /editpost/?postuid=19348&postuid=1 la chaîne de requête serait analysée différemment pour les parties de code qui effectuent l'autorisation (celles-ci devraient vérifier l'autorisation sur postuid=19348) et l'édition réelle (ceux-ci devraient être édités pour postuid=1).
Ce n'est pas un problème courant dans les applications Web modernes car l'analyse des paramètres est généralement effectuée par le framework, dans (les versions modernes de) php par exemple, $_GET["postuid"] contiendrait la même valeur pour les deux fragments de code, rendant une attaque HTTP PP inutile).
HTTP PP était un gros problème (et l'est toujours, chaque fois que c'est le cas) lorsque les paramètres sont analysés "à la main", c'est-à-dire sur la couche logique d'application. Cela ouvre la porte à différents les gens implémentant cette analyse différemment.