Cross site scripting d'attaques et de même origine

Je suis familier avec le persistants et non persistants XSS.
Je connais aussi Même la politique de l'origine qui empêche/limiter les demandes provenant de l'un des sites web page pour aller à un autre site web serveurs. Cela m'a fait penser que la même politique d'origine peut s'arrêter à au moins la non-persistant type d'attaques XSS (Parce que par la persistance du type d'attaque, le code malveillant origine pourrait être le même que l'information privée qui a été volé).
Est ma compréhension correcte? Peut SOP être utilisé d'arrêter ou de réduire ces attaques?

EDIT: Bon j'ai été source de confusion entre l'invocation de méthodes entre 2 scripts sur le navigateur côté et de l'invocation de méthodes telles que HTTP POST sur un autre site. Merci pour la réponse jakber.

Maintenant j'ai une autre question, ne serait pas SOP être en mesure de prévenir Cross-site request forgery?
L'exemple donné dans le wikipedia parle de Bob l'accès à un malveillant balise d'image créé par Mallory sur le chat du forum. Cependant, conformément à la SOP règle, le script malveillant ne devrait pas être en mesure d'accéder à la banque de cookie. Suis-je manqué quelque chose?

SOP n'est pas quelque chose de commencer ou d'arrêter. C'est toujours appliquée dans votre navigateur, si malheureusement il ne s'arrête pas CSRF. Dans l'avenir peut-être quelque chose comme CSP peut être en mesure d'arrêter ces attaques, mais actuellement, la base de jeton d'approches sont le meilleur moyen d'éviter CSRF.

OriginalL'auteur Methos | 2011-08-10

  1. 8

    Généralement pas.

    Un non-persistant ou réfléchie attaque XSS exploits d'entrée qui est fait l'écho de retour en tant que contenu de la page sans assainissement, sans persistance. L'injection de script ne semble pas provenir de l'exploitation du domaine dans les deux cas.

    Par exemple si vous faites cela en PHP: echo $_GET['param'] et envoyer un lien à la page à quelqu'un contenant
    ?param=<script>alert('got you!');</script>
    c'est un non-persistant attaque XSS, et de même origine politique n'a rien à faire avec elle.

    De même origine " signifie que vous ne pouvez pas injecter directement des scripts ou de modifier le DOM sur d'autres domaines: c'est pourquoi vous avez besoin de trouver une vulnérabilité XSS pour commencer.

    Merci pour la réponse. Avez-vous des commentaires au sujet de mes nouvelles vérifications?
    SOP ne s'applique pas à la src des images, le style, iframe et des éléments de script, ni à la cible de formes par exemple. Elle ne s'applique toutefois XmlHttpRequest, de sorte qu'il empêche ce vecteur d'attaque pour CSRF. Voir aussi owasp.org/index.php/...

    OriginalL'auteur jakber

  2. 0

    SOP ne peut habituellement pas d'empêcher les attaques de type XSS ou CSRF.

    Pour les XSS, jakber la réponse de l'offre déjà une bonne explication. Je veux juste ajouter que la raison d'appeler cette vulnérabilité cross-site" est parce que l'attaquant peut injecter du code (par exemple,<script src="...">) dans la page cible qui se charge javascript malveillant à partir d'un autre site web, qui est généralement contrôlé par l'attaquant. Chargement du Javascript à partir d'un autre site web n'est pas refusé par le SOP, car cela qui va briser le Web.

    Pour CSRF, SOP ne peut pas l'empêcher, pour la plupart des cas, parce que, SOP n'empêche pas Un site web pour envoyer des GET et POST demandes de site B.

    Si je comprends bien, SOP empêche d'OBTENIR. C'est en effet le point de l'ensemble de la SOP, pour éviter qu'un script silencieusement à l'aide d'un navigateur (après authentification (authentifié avec un cookie) à partir de la lecture de fichiers à partir d'autres pages (comme ces sources pourraient être confidentielles si le navigateur est déjà authentifié). POST sur l'autre main, est autorisé.
    Selon Mozilla, les pages web peuvent intégrer du JavaScript à partir d'autres origines.

    OriginalL'auteur ZillGate