wikipedia fournit Informations sur l'un des scénarios les plus courants Pour exploiter une attaque de script de site croisée réfléchie - en utilisant un certain degré d'ingénierie sociale pour induire des utilisateurs sans méfiance à cliquer sur un lien malveillant:
- Alice visit souvent un site Web particulier, qui est hébergé par Bob. Bob Le site Web permet à Alice de se connecter avec un Nom d'utilisateur / couple de mots de passe et magasins données sensibles, telles que la facturation informations.
- Mallory observe que le site Web de Bob contient un XSS réfléchi vulnérabilité.
- mallory artisanat une URL à exploiter la vulnérabilité et envoie Alice An email, l'attrayant pour cliquer sur un lien pour l'URL sous de faux prétextes. Cette URL pointera vers le site Web de Bob, mais contiendra la malveillante de Mallory code, que le site Web réfléchira.
- Alice visite l'URL fournie par Mallory lors de la connexion à Bob Site Web.
- Le script malveillant intégré à l'URL s'exécute dans le navigateur d'Alice, Comme s'il était venu directement de Bob's serveur (c'est le XSS réel vulnérabilité). Le script peut être utilisé Pour envoyer le cookie de session d'Alice à Mallory. Mallory peut alors utiliser le Cookie de session pour voler sensible Informations disponibles pour Alice (Critiques d'authentification, facturation Info, etc.) Sans la connaissance d'Alice.
Maintenant, cela a généralement tendance à être très bon exemple lorsque le site Web doit être une application axée sur la page - la vulnérabilité est exploitée en demandant à l'utilisateur de soumettre une charge utile malveillante à l'application (plus important encore, en émettant un get Demande lorsque connecté) qui est reflété dans la réponse.
Y a-t-il des vecteurs d'attaque plus intéressants, en particulier ceux à considérer lorsque l'application utilise beaucoup d'AJAX avec la plupart des demandes effectuées via la poste HTTP?
Modifier Au cas où je n'étais pas clair, j'aimerais connaître les différents types de vecteurs d'attaques applicables aux attaques de XSS réfléchies, en particulier lorsque le niveau du client de la demande est mis en œuvre différemment. Les applications basées sur la page auraient un vecteur d'attaque impliquant des demandes HTTP Obtenir des demandes émises d'un utilisateur, mais il serait intéressant de savoir comment cela joue pour les applications client épaisses, en particulier celles utilisant des objets XMLHTTPRequest qui publient des demandes de post HTTP. Différents mécanismes utilisés dans le rendu côté clientject justifient évidemment l'étude de différents vecteurs d'attaque. Dans certains cas, il n'ya peut-être pas de vecteurs d'attaque applicables; La question est exprimée pour susciter une telle réponse.
3 Réponses :
Oui, il y a en fait quelques variations de l'attaque réfléchissante XSS. La plupart du temps, c'est le Samy Worm . En bref, Samy a utilisé XSS pour tirer un XHR à MySpace.com pour lire le jeton CSRF et la demande de post forge. En fait, il s'agit d'un modèle d'attaque générale utile pour attaquer des sites qui utilisent httponly cookies . Comme l'utilisation de biscuits httponly devient plus populaire, ce modèle d'attaque sera donc aussi populaire.
Une autre charge utile XSS est la coquille XSS . Ceci fournit à l'attaquant un canal interactif au navigateur.
XSS est utilisé pour livrer un " Drive-Parloffe " Attack.
XSS peut également être utilisé pour
edit: Vous pourriez aussi être intéressé comment la fondation Apache possédé en utilisant XSS et TinyURL.
Merci pour la réponse; Certains des liens sont intéressants. Je viens de finir de lire le papier sur la coquille XSS. Pour clarifier ce que je recherche, j'étais effectivement intéressé à en savoir plus sur le processus initial «infection» plus que ce qui peut être atteint après l'infection. La question est gracieusement, la question est "Comment exploitez-moi la vulnérabilité réfléchie XSS dans une application, avec une certaine quantité d'ingénierie sociale impliquée?". Étant donné que toutes les applications ne sont pas construites semblables, tirant une attaque contre Gmail différente par rapport à CNN; C'est exemple trop étroit, mais j'espère que vous obtenez l'idée.
@Vineet Reynolds Pour être honnête, c'est pour les questions de programmation, et je suis plus intéressé par la rédaction de code d'exploit que de tromper les gens à cliquer sur des liens. Si vous êtes intéressé par l'ingénierie sociale, vous devriez regarder ailleurs. Cependant, vous êtes peut-être intéressé par mon édition.
Rook, juste au cas où je n'ai pas été mal compris, je ne m'intéresse pas également à l'aspect technique social. En ce qui concerne l'exploitation de la préparation, je n'ai rien vu au-delà du simple type d'attaques liées à un courrier électronique. C'est pourquoi je suis intéressé à savoir comment des exploits sont écrits si le formulaire HTTP soumet ou XHR doit être utilisé. Je crois que le deuxième lien contient une réponse à ce que je cherche.
@Vineet Reynolds AAH, puis oui, je me référerais à mon exploit PLIGGG. Si vous souhaitez en savoir plus sur le CSRF, vous devez lire le manuel Google Browserec dans son intégralité.
XSS réfléchi se produit lorsqu'une page affiche une entrée d'utilisateur malveillante. La question "Quels vecteurs d'attaque sont là?" est donc synonyme de "quelle entrée utilisateur peut-elle recevoir une page?"
Certaines sources sont:
Je me rends compte que les "autres formes de saisie" ressemblent davantage à une vulnérabilité XSS stockée, mais chaque application est unique, et certaines peuvent traduire l'entrée de l'utilisateur dans la manière dont les pièces externes sont composées dans la page (par conséquent, réfléchie).
Une chaîne de requête dans une demande d'obtention d'un email phispécifique n'est certainement pas le seul vecteur pour XSS réfléchi (bonne question cependant).
Benlbroussard a déjà touché cela, mais je veux le réitérer à cause de l'importance. Client gras, client léger, post, obtenir, mettre; aucune de ces choses ne compte. Un trou XSS est basé sur un site rendant de manière incorrecte une entrée à quelqu'un.
Si vous recherchez une attaque strictement réfléchie, la charge utile ne doit pas être stockée nulle part dans l'application cible. Dans ce cas, je pense que vous avez raison pour que vous ayez raison qu'un client de graisse évoluera à être plus résistant, car un get est les moyens les plus faciles d'initier une attaque réfléchie XSS.
En ce qui concerne plus de vecteurs d'attaque, une chose intéressante sur l'architecture client FAT est une entité codée. Un client léger peut tout coder tout et être fait avec elle, avec un grand avantage. Un client de graisse Si l'entité doit encoder la réponse à une entrée initiale, mais les demandes asynchrones avec des réponses à la tête de JavaScript ne peuvent pas être codées (entièrement) codées et être valides JS. Cette bilan et arrière augmente les chances de ne pas encoder quelque chose qui devrait être, ce qui est un grand pas vers la création d'un vecteur XSS.
sens?
carl
Tout a du sens, à l'exception de l'encodage de l'entité des demandes par le client. Je pense que les clients devraient utiliser les règles de codage comme stipulé dans le protocole sous-jacent (HTTP), car plusieurs codages en place peuvent entraîner des attaques utilisant plusieurs niveaux d'encodage. Cela de côté, la plupart des autres choses ont un sens - Ajax (avec XML dans la réponse) est meilleur que AJAH (avec HTML) si l'on doit protéger contre XSS est quelque chose que j'ai dérivé.
@Vineet, bonne affaire. J'ai bien peur que mon message soit mal écrit, j'avais fait référence à l'entité codant des réponses du serveur, et non des demandes du client. Grande différence non? Je ne comprends pas comment XML est meilleur que HTML. Ma pensée est que tout ce qui compte, c'est comment vous utilisez la réponse dans JS, et cela informe comment il doit être protégé. L'évaluation de JS introduit certains vecteurs, l'insérer dans le DOM introduit les autres. Qu'est-ce que je rate?
L'injection DOM est un sujet intéressant. Encore une fois dériver une idée ici - JavaScript qui est présent (dans une section CDATA peut-être) dans la réponse du serveur (qui est un document XML), peut être interprété si le développeur a mis en place la logique de présentation de cette manière. Certainement pas une bonne pratique, cela n'empêchera pas aux gens de coder une telle monstruosité, qui se prête comme une avenue d'attaque. Je ne pensais pas à cela plus tôt et j'ai donc supposé que Ajax est plus sûr que Ajah.
Je suggérerais que ServerFault pourrait être un lieu plus approprié pour cette question ou, peut-être, webmasters.stackexchange.com
@ tirebowl, mais pourquoi voudrais-je le mettre sur serverfault? Je ne cherche pas conseil à durcir un serveur. J'essaie de déduire un ensemble de vecteurs d'attaque sur une application Web. C'est quelque chose que les gens bien versés dans la sécurité peuvent répondre. La façon dont je le vois, c'est une question de conception de sécurité - si une vulnérabilité à réfléchir XSS soit prise au sérieux si une application est écrite de manière particulière?
Je ne suggère pas entièrement que SF est le bon lieu, je suis juste en train de regarder les deux votes proches qui suggèrent de migrer à sf. Personnellement, je pense que webmasters.stackexchange.com serait un meilleur choix, bien que l'un d'entre eux serait un meilleur choix que cela, précisément à cause de la mise au point basée sur le serveur de ces sites (et de la mise au point sur web de cette question). Les utilisateurs de ces sites pourraient évidemment se sentir différemment que moi.
@ tirebowl juste parce que vous ne pouvez pas répondre à la question ne signifie pas que cela ne devrait pas être allumé. Je pense que nous savons tous les deux que cette question n'aurait jamais répondu à l'un des obscurs Stackexchange.