Code vulnérable suggéré sur Owasp?
Prévention de la session du détournement
Il est une bonne pratique de lier des sessions aux adresses IP, cela empêcherait la plupart des scénarios de détournement de la session (mais pas tous), mais certains utilisateurs peuvent utiliser des outils d'anonymat (tels que TOR) et ils auraient des problèmes avec votre service.
Pour mettre en œuvre cela, stockez simplement l'adresse IP du client dans la session pour la première fois, elle est créée et appliquez-la comme la même par la suite. L'extrait de code ci-dessous renvoie l'adresse IP du client:
$ IP = (getenv ("http_x_forwarded_for"))? getenv ("http_x_forwarded_for"): getenv ("Remote_addr");
Source: https://www.owasp.org/index.php/php_security_cheat_sheet#session_hijacking_prevention
Il me semble que ce code est vulnérable à l'usurpation IP! Droit?
EDIT: AFIK, X_FORWARDED_FOR est une en-tête HTTP qui est très facile pour les clients à définir sur tout ce qu'ils veulent.
Ce code permet à un attaquant qui connaît la victime X-Forwarded-For: Rubrique et ID de la session de la victime pour vous connecter à cet utilisateur. Si la victime n'a pas de X-Forwarded-For: En-tête, l'attaquant peut mettre l'adresse IP de la victime dans son en-tête et que le code utilisera cette valeur comme adresse IP légitime au lieu de son adresse IP réelle. C'est la vulnérabilité .
Dans un scénario de renonciation au réseau, l'attaquant obtient à la fois ces deux valeurs en même temps, d'où l'ajout de ce code ne protège pas contre le reniflement du réseau.
Dans un scénario XSS, où l'attaquant injecte JavaScript pour voler le cookie de l'utilisateur, cela provoque généralement le navigateur de la victime de faire une demande à un serveur Web contrôlé par attaquant avec la valeur de cookie ajoutée en tant que paramètre d'obtention. Les
X-Forwarded-For:L'en-tête de la victime serait fourni à l'attaquant de cette demande.
Je n'ai pas encore pu penser à aucun scénario où un attaquant pouvait obtenir le cookie d'une victime mais ne peut pas obtenir la valeur d'une légitime X-Forwarded-For: En-tête ou, si aucun en-tête n'était présent, l'adresse IP de la victime.
La réponse est donc oui, comme écrit, ce code ne fait rien pour améliorer la sécurité. Il devrait faire confiance à l'adresse IP directement connectée uniquement .
REMARQUE : Si votre serveur d'applications Web est derrière un proxy Web inverse (tel que NGinx, vernis, Haproxy, Mod_Proxy, Amazon ELB et de nombreux autres) ajoute toujours l'adresse IP de connexion à un X-Forwarded-For En-tête et crée une nouvelle connexion à votre serveur d'applications Web avec sa propre adresse IP, vous pouvez "faire confiance" pièce de la valeur de cet en-tête.
Modules tels que mod_rpaf ou mod_remoteip Pour Apache peut être configuré avec une liste d'adresses IP proxy de confiance et remplacera la valeur de REMOTE_ADDR avec la partie de confiance du X-Forwarded-For En-tête pour les connexions provenant de ces adresses. Cette REMOTE_ADDR sera disponible en PHP comme $_SERVER['REMOTE_ADDR] Et sera connecté à vos fichiers journaux Apache comme une adresse IP de Connexion true.
Si vous ne faites pas cela (ou l'équivalent si vous n'utilisez pas Apache), vous ne verrez jamais les connexions d'une adresse IP, votre serveur de proxy inverse, et toutes vos sessions contiendront la même adresse IP.
Je dirais que tu as raison! Ils ne semblent pas avoir gardé à l'esprit que l'en-tête HTTP X-transféré - pour peut-être retourner '; DROP TABLE users;--.
Ils suggèrent cela afin de verrouiller également des sessions pour les personnes derrière des mandataires et de Nom Tor comme exemple. C'est une sorte de stupide; Tor n'envoie jamais l'IP d'origine pour des raisons évidentes. De plus, ce n'est pas (ne devrait pas?) Regardez même le paquet lui-même; Il ne le transforme que jusqu'à ce qu'il soit hors du réseau. Quelle est l'utilisation d'un proxy si l'adresse IP originale est transmise de toute façon? Il suffit de verrouiller à l'adresse distante, c'est le seul pari sûr. Même si vous deviez valider l'en-tête X-Forwed-pour l'adresse IPv4 ou IPv6 valide, il peut toujours contenir une adresse IP arbitraire.
Au-dessous du code exemple de cette page, ils pensent que les IPS et IPv6 locaux (même si les exemples IPv6 contiennent des adresses non valides):
Gardez à l'esprit que dans les environnements locaux, une adresse IP valide n'est pas retournée, et généralement la chaîne ::: 1 ou ::: 127 pourrait apparaître, adaptez ainsi votre logique de vérification IP.
Mais ils auraient également dû penser à ce que l'en-tête peut contenir des données arbitraires. Belle trouver!
Comme il s'agit d'un wiki, je suppose que quiconque comporte un compte pourrait modifier la page. Sinon, vous devez les contacter. C'est en effet une mauvaise pratique, et beaucoup de gens pourraient même insérer $IP non découvert dans une base de données. Il n'est généralement pas possible de spoiser la variable environnementale de Remote_AdDRDDRDDRDDRDDR, il convient de veiller dans des circonstances normales (bien que je ne l'insérerais pas non évaluée même si c'était le cas), mais l'en-tête X-Forfait-pour-en-tête.
Ce code est un contrôle de sécurité et, en tant que tel, il doit être évalué contre la menace qu'elle visait à contrôler. Dans ce cas, aucun accès spécial n'est accordé en fonction de l'adresse IP. Au lieu de cela, l'adresse IP est utilisée comme une contrainte supplémentaire sur un mécanisme d'autorisation déjà solide (cookies HTTP).
Il est vrai qu'un attaquant pouvait étourner la propriété intellectuelle d'un utilisateur via l'en-tête X-Forwarded et contourner ce contrôle supplémentaire, mais cela signifie que l'attaquant doit non seulement connaître l'identifiant de session de l'utilisateur (cookie), mais également l'adresse IP de l'utilisateur. Cela fait de l'exploitation de la session - voler des XSS plus difficile.
Considérez les autres moyens que ce contrôle aurait pu être approché. Premièrement, si le contrôle n'était pas en place du tout, toute attaque de la session-voler (XSS, trafic reniflant, SSL Mitm, etc.) entraînerait une session complète utilisable pour l'attaquant, sans aucun travail supplémentaire.
Au lieu de cela, si le contrôle a été mis en œuvre sans consulter l'en-tête X-Forwarded, mais seulement http_remote_addr, alors un attaquant qui est derrière le même proxy (dans une école ou une entreprise, par exemple) n'aurait besoin d'aucune connaissance du contrôle ou de la L'IP interne de l'utilisateur doit avoir une session entièrement utilisable, car toutes les sessions HTTP sortantes sembleraient provenir de la même adresse IP (celle du proxy).
En ajoutant la vérification de la commande X-for, la commande nécessite qu'un attaquant ait une connaissance de l'adresse IP de l'utilisateur et la possibilité de la transpirer dans l'en-tête transmissionné de X (tout attaquant n'est pas complètement non contraint. Il y a donc une réduction de risque. Pas une élimination du risque, puisque nous devons supposer qu'il existe des attaquants non contraints.)
Une façon d'éventuellement renforcer ce contrôle serait de garder un peu d'informations supplémentaires: la source de la dernière adresse IP utilisée. Par exemple, si la session a été acceptée et associée à une adresse IP provenant de http_remote_addr, le contrôle pourrait exiger que le trafic futur de cette session doit provenir d'une propriété intellectuelle glanée de http_remote_addr, et non de X-Forwarded. Cela élimine certaines possibilités d'usurper. Les gains pour la mise en oeuvre de la vérification inverse (préférant X-Forwarded-for sur http_remote_addr) ne vaut probablement pas l'effort, car il est beaucoup plus difficile de spoof une adresse réseau réelle que d'un en-tête HTTP.