Quel est le danger du Reflected Cross Site Scripting?
Quel est le danger du Reflected Cross Site Scripting?
Je comprends que le Reflected XSS est dangereux, car c'est possible. Mais quelles attaques pratiques peuvent être effectuées en utilisant Reflected XSS?
Vous pouvez faire beaucoup lorsque vous pouvez injecter du code dans une page. Par exemple, vous pouvez
- voler les informations d'identification dans les cookies non HTTPOnly.
- envoyer des demandes à un serveur avec les informations d'identification de l'utilisateur. Pensez XSRF
- voler des secrets stockés dans des variables JS.
- Inviter l'utilisateur à télécharger du contenu en soumettant un formulaire
- afficher du texte qui semble provenir des propriétaires du site. Pensez au phishing.
- afficher une entrée de mot de passe, enregistrer les frappes et envoyer le résultat à un site de votre choix
- rediriger vers un autre site
- obtenir des données GPS/caméra si l'utilisateur a accordé à ce site l'accès à l'appareil
Le article wikipedia rend justice:
La vulnérabilité de script intersite non persistante (ou reflétée) est de loin le type le plus courant. Ces trous apparaissent lorsque les données fournies par un client Web, le plus souvent dans les paramètres de requête HTTP ou dans les soumissions de formulaires HTML, sont immédiatement utilisées par les scripts côté serveur pour générer une page de résultats pour cet utilisateur, sans filtrer correctement la demande.
Étant donné que les documents HTML ont une structure série plate qui mélange les instructions de contrôle, la mise en forme et le contenu réel, toutes les données fournies par l'utilisateur non validées incluses dans la page résultante sans codage HTML approprié peuvent entraîner une injection de balisage. Un exemple classique d'un vecteur potentiel est un moteur de recherche de site: si l'on recherche une chaîne, la chaîne de recherche sera généralement affichée de nouveau textuellement sur la page de résultats pour indiquer ce qui a été recherché. Si cette réponse n'échappe pas ou ne rejette pas correctement les caractères de contrôle HTML, une faille de script intersite s'ensuivra.
Une attaque réfléchie est généralement livrée par e-mail ou sur un site Web neutre. L'appât est une URL d'apparence innocente, pointant vers un site de confiance mais contenant le vecteur XSS. Si le site de confiance est vulnérable au vecteur, cliquer sur le lien peut amener le navigateur de la victime à exécuter le script injecté.
...
Non persistant (aka réfléchissant):
- Alice visite souvent un site Web particulier, hébergé par Bob. Le site Web de Bob permet à Alice de se connecter avec une paire nom d'utilisateur/mot de passe et stocke des données sensibles, telles que des informations de facturation.
- Mallory observe que le site Web de Bob contient une vulnérabilité XSS reflétée.
- Mallory crée une URL pour exploiter la vulnérabilité et envoie un courriel à Alice, l'incitant à cliquer sur un lien pour l'URL sous de faux prétextes. Cette URL pointera vers le site Web de Bob (directement ou via un iframe ou ajax), mais contiendra le code malveillant de Mallory, que le site Web reflétera.
- Alice visite l'URL fournie par Mallory lorsqu'elle est connectée au site Web de Bob.
- Le script malveillant intégré à l'URL s'exécute dans le navigateur d'Alice, comme s'il provenait directement du serveur de Bob (il s'agit de la vulnérabilité XSS réelle). Le script peut être utilisé pour envoyer le cookie de session d'Alice à Mallory. Mallory peut ensuite utiliser le cookie de session pour voler des informations sensibles disponibles pour Alice (informations d'authentification, informations de facturation, etc.) à l'insu d'Alice.
Avez-vous des questions à ce sujet?
La défense XSS standard fonctionne contre elle; par exemple, désinfecter les entrées utilisateur non fiables; par exemple, laissez-les uniquement insérer un petit sous-ensemble de HTML (à partir d'un langage de balisage limité sécurisé) ou passer par un bon assainisseur/purificateur html, n'utilisez pas de modèles dangereux dans les scripts (par exemple, évaluez en javascript sur l'entrée utilisateur), utilisez idéalement un navigateur avec CSP et sandboxing, etc.
De OWASP :
Attaques XSS reflétées: les attaques reflétées sont celles où le code injecté est reflété par le serveur Web, comme dans un message d'erreur, un résultat de recherche ou toute autre réponse incluant une partie ou la totalité des entrées envoyées au serveur dans le cadre de la demande. . Les attaques reflétées sont transmises aux victimes via un autre itinéraire, comme dans un message électronique ou sur un autre serveur Web. Lorsqu'un utilisateur est amené à cliquer sur un lien malveillant ou à soumettre un formulaire spécialement conçu, le code injecté se rend sur le serveur Web vulnérable, ce qui renvoie l'attaque au navigateur de l'utilisateur. Le navigateur exécute ensuite le code car il provient d'un serveur "de confiance".
Cela signifie que je peux insérer du code malveillant dans les paramètres de requête (la partie de l'URL après l'esperluette ou le point d'interrogation. Je peux envoyer un e-mail malveillant, utiliser bit.ly ou similaire, ou combiner avec d'autres attaques pour obtenir vous faire une demande involontaire, qui ne filtre pas pour le XSS.
En termes d'attaques, le phishing va être le plus gros, amener quelqu'un à faire confiance à mon mauvais lien. Ce type d'attaque peut également être combiné avec CSRF ou n'importe laquelle d'un certain nombre d'attaques, à tout moment et l'attaquant peut obtenir un autre site pour exécuter son code, et vous pour exécuter la page avec javascript activé, ça va être mauvais.
Quelques liens
Je vous recommande de jeter un œil à BeEF - The Browser Exploitation Framework http://beefproject.com/ C'est essentiellement un outil pour montrer les dangers de XSS. En utilisant une attaque XSS réfléchie ou persistante, le boeuf se connecte au site Web donné et permet à l'attaquant de contrôler le navigateur sur la page donnée. BeEF s'intègre à Metasploit, ce qui permet à un attaquant d'envoyer des exploits de navigateur, etc. au navigateur de l'utilisateur. Vous pouvez voler des données, voler des sessions, etc. Il y a aussi des vidéos décentes.
Tout ce que BeEF peut faire, les attaquants peuvent aussi le faire. XSS peut être assez mauvais.