Le XSS reflété est-il toujours d'actualité?
J'en ai appris plus sur XSS (pour les inconnus, Excess XSS est une excellente ressource). J'ai choisi de me salir les mains et d'essayer Reflected XSS sur un environnement local. J'ai mis en place une page vulnérable très simple PHP fonctionnant sur Apache2 qui prend un paramètre URL et décharge le contenu dans la page:
<!DOCTYPE html>
<html>
<head>
<title>VULNERABLE WEBSITE</title>
</head>
<body style="background-color:#98FB98">
<h1>VULNERABLE WEBSITE</h1>
<p>Search results for <?php echo $_GET['query']; ?>:</p>
</body>
</html>
Ensuite, j'ai tenté d'intégrer du JavaScript "malveillant" dans la page à l'aide d'une URL telle que la suivante:
http://localhost:8082/?query=<script>alert('Hello!');</script>
J'ai trouvé que les navigateurs eux-mêmes empêchaient que cela se produise. Dans Firefox, cela m'a conduit à une page de recherche Google. Dans Chromium, le XSS a été spécifiquement détecté et bloqué:
Donc, passant de la théorie à la pratique, je me demande maintenant: Reflected XSS est-il toujours un problème de sécurité pertinent aujourd'hui?
Cela ne s'applique évidemment pas à XSS persistant où le contenu malveillant est servi directement par le site Web lui-même.
Reflected XSS n'est pas seulement par GET. Cela peut être par POST aussi. Et ils ne sont pas toujours empêchés par les navigateurs. Et bien sûr, c'est toujours pertinent.
Quelques définitions:
- https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
- https://www.acunetix.com/websitesecurity/xss/
Et à partir de la base de connaissances Checkmarx, il est écrit: " Le XSS le plus couramment trouvé ". Extrait de ici . Donc, si c'est le plus commun, je pense qu'il est toujours pertinent.
Oui, toutes les formes de XSS sont toujours pertinentes aujourd'hui.
L'attaque particulière que vous avez essayée était évidente pour le navigateur heuristiquement trouver, mais le code généré par des injections plus subtiles pourrait ne pas l'être. Que faire si je modifie l'URL de soumission d'un formulaire parce que le développeur a utilisé <form action="{$_SERVER['PHP_SELF']}"? Et si je change votre message d'erreur en un message de confirmation? Que faire si je modifie le hachage SHA1 affiché d'une distribution Linux que vous avez téléchargée?
Ne comptez jamais sur les fonctionnalités côté client (les navigateurs Web en particulier) pour assurer la sécurité de vos utilisateurs.
Les cas les plus courants et les plus triviaux de XSS réfléchi - où vous sortez littéralement exactement ce qui a été fourni (<?php echo $_GET['query']; ?>) Et il fonctionne tel quel - ne sont pratiquement pas pertinents dans les navigateurs modernes par défaut, non.
Cependant, "reflété XSS" en tant que catégorie est un peu plus large que cela. Cela inclut également les cas où l'entrée est codée d'une manière ou d'une autre. Un exemple que j'ai vu dans la nature est la réflexion du code HTML codé en base64, comme <?php echo base64_decode($_GET['query']); ?>. Les filtres du navigateur n'attraperont probablement pas cela.
Vous devez également prendre en compte les cas où le code ne s'exécute pas seul, mais il existe un autre JavaScript qui entraînera son exécution ultérieure. La façon la plus courante de procéder est une bibliothèque de modèles côté client qui interprète les expressions dans ce qui serait autrement du texte statique. Par exemple, considérons ce cas où les attributs dyn- Sont évalués côté client avec des données de modèle:
<img dyn-src="model.get('<?php echo $_GET['name']; ?>')" />
<script>
let model = { something... };
for (let el of document.querySelectorAll('[dyn-src]')) {
el.src = eval(el.getAttribute('dyn-src'));
}
</script>
Cela permet une forme de XSS réfléchi avec quelque chose comme ?name=', alert('xss'), ', que les navigateurs ne verront probablement pas non plus.
Reflected XSS est toujours pertinent car tous les navigateurs n'implémentent pas les mêmes filtres de la même manière, parfois un contournement est découvert pour certaines implémentations, par conséquent l'auditeur peut ne pas le bloquer.
Certains sites n'ont pas le X-XSS-Protection en-tête activé, donc ces sites sont également vulnérables
Et, comme indiqué dans une autre réponse, la charge utile peut être fournie via POST au lieu de GET, empêchant l'auditeur de bloquer l'injection malveillante
Enfin, même si tout est correctement configuré et qu'il n'y a pas de contournement connu pour l'implémentation du filtre, ce n'est qu'un filtre. Il bloque certains XSS réfléchis mais comme il y a de faux positifs, il y a trop de faux négatifs, donc la charge utile reste non détectée
Oui.
D'une part, Firefox n'a pas encore de filtre XSS, donc les attaques réfléchies peuvent être exécutées sur ce navigateur.
De plus, XSS basé sur DOM contourne les filtres du navigateur. Ceci n'est pas strictement catégorisé comme "XSS réfléchi" , cependant le résultat final est le même.
Une autre chose à garder à l'esprit est que les auditeurs XSS de navigateur ne constituent pas une limite de sécurité. De Google :
Non, les contournements d'auditeur XSS ne constituent pas Chrome (c'est pourquoi ce bogue est signalé SecSeverity-None). Vous pouvez trouver nos consignes de gravité ici: http: // dev.chromium.org/developers/severity-guidelines
Pour clarifier un peu plus, l'auditeur XSS est un mécanisme de défense en profondeur pour protéger nos utilisateurs contre certaines vulnérabilités XSS courantes dans les sites Web. Nous savons pertinemment qu'il ne peut pas attraper toutes les variantes XSS possibles, et celles qu'il attrape doivent encore être corrigées sur le site affecté. Ainsi, l'auditeur est vraiment un filet de sécurité supplémentaire pour nos utilisateurs, mais n'est pas conçu comme un mécanisme de sécurité solide.
Il existe des contournements trouvés dans ces mécanismes de navigateur tout le temps. exemple IE ici . Et, contrairement à une autre réponse ici, les filtres tentent de bloquer POST aussi . Cependant, vous ne pouvez jamais compter sur ces filtres pour bloquer tous les XSS.
Le résultat est que vous devez atténuer XSS sur votre application Web en utilisant l'encodage de sortie, le filtrage/validation des entrées (si possible) et, espérons-le, une solide politique de sécurité du contenu.
Le filtrage et la validation des entrées peuvent parfois être difficiles, mais si vous prenez des entrées où la seule entrée valide est par exemple des chiffres et des lettres, si vous voulez une application sécurisée, il est judicieux de limiter les jeux de caractères aux seuls utiles. Bien sûr, cela n'est pas possible si vous exécutez un site de style Stack Overflow où vous autorisez des extraits de code et qui utilisent un grand jeu de caractères.
N'oubliez pas que XSS reflété nécessite qu'un utilisateur suive ou soit redirigé vers une URL. Par conséquent, il faut parfois un peu d '"ingénierie sociale" d'un attaquant pour l'exploiter. Je classe généralement XSS reflété comme une vulnérabilité à risque moyen, sauf s'il peut être exploité automatiquement à partir de l'application (par exemple, une redirection automatique quelque part) ou si l'application elle-même est particulièrement sensible.
Oui:
- Ne pas corriger les failles de sécurité connues est toujours une mauvaise idée, mais aussi ...
- Les principaux navigateurs qui ont tenté de bloquer le XSS réfléchi envisagent de retirer la technologie.
Je comprends d'où vient cette question, mais la technologie n'est malheureusement pas parfaite et n'arrête presque jamais un attaquant déterminé:
Au cours des 3 derniers mois, nous avons enquêté sur tous les bogues XSS internes qui ont déclenché XSSAuditor et avons pu trouver des contournements pour chacun d'eux.
C'est l'équipe de Chromium, annonçant leur conseil Chrome pour supprimer le XSSAuditor . La raison donnée est la suivante:
Nous n'avons trouvé aucune preuve que XSSAuditor arrête tout XSS, et au lieu de cela, nous avons eu des difficultés à expliquer aux développeurs à grande échelle, pourquoi ils devraient corriger les bogues même lorsque le navigateur dit que l'attaque a été arrêtée.
Et non seulement cela amène les développeurs à se demander s'ils doivent appliquer des correctifs, mais cela empêche également les testeurs de sécurité de faire leur travail. Puisqu'ils ont du mal à justifier en quoi il s'agit d'un risque sans trouver de dérivation (parfois longue):
De plus, nous avons interrogé des pentesters de sécurité et découvert que certains ne signalent pas de vulnérabilités à moins qu'ils ne trouvent un contournement de XSSAuditor, ce qui signifie que les équipes de défense finissent par être encore plus handicapées que les attaquants (en tant qu'équipes de défense, car les équipes de défense doivent évoluer) leurs efforts de correction, alors que les attaquants n'ont besoin que de quelque chose qui fonctionne).
Microsoft est moins ouvert sur son raisonnement, mais aussi a annoncé en juin dernier qu'il allait retirer le filtre XSS :
Filtre XSS retiré: nous supprimons le filtre XSS dans Microsoft Edge à partir de la version d'aujourd'hui. Nos clients restent protégés grâce à des normes modernes comme Politique de sécurité du conten , qui fournissent des mécanismes plus puissants, plus performants et plus sûrs pour se protéger contre les attaques par injection de contenu, avec compatibilité élevée entre les navigateurs modernes .
Un autre bon article de blog sur le sujet est celui-ci: https://portswigger.net/daily-swig/xss-protection-disappears-from-Microsoft-Edge
Par exemple, il est lié à des recherches qui montrent que le filtre XSS dans MSIE conduit parfois à des vulnérabilités qui autrement n'auraient pas été exploitables.
Oui, c'est toujours d'actualité. Vous pouvez essayer de suivre pour votre échantillon:
http://localhost:8082/?query=<svg onload="alert('Hello!')"/>