Pourquoi la croix-domaine Ajax est un problème de sécurité?
Pourquoi il a été décidé que l'utilisation de XMLHTTPRequest pour faire du XML appels ne devraient pas faire appelle, au-delà de la limite du domaine? Vous pouvez les récupérer en JavaScript, les images, les CSS, les iframes, et juste au sujet de tout autre contenu que je peux penser à d'autres domaines. Pourquoi l'Ajax requêtes HTTP sont pas autorisés à franchir les limites du domaine? Il semble étrange limitation de mettre, en considérant la seule façon que je considère que c'est abusé, serait si quelqu'un venait à injecter du code Javascript dans la page. Toutefois, dans ce cas, vous pouvez simplement ajouter une img, script, ou de l'élément iframe pour le document pour obtenir de demander à la troisième partie de l'URL et de l'envoyer au serveur.
[Modifier]
Certaines réponses soulignent les raisons suivantes, faisons le point sur les raisons pour lesquelles ils ne créent pas de raison majeure pour interdire ce.
XSRF (Cross Site Request Forgery, aussi connu comme CSRF, XSRF)
Votre peut faire XSRF attaques sans l'aide de ce tout. En règle générale, XMLHTTPRequest n'est pas du tout, tout simplement parce que c'est tellement difficile de faire un XMLHTTPRequest dans une manière qui est compatible avec tous les principaux navigateurs. Il est beaucoup plus facile de simplement ajouter une balise img pour l'URL si vous voulez charger votre URL.
L'affichage vers le site tiers
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>Peut être accompli grâce à
<body onload="document.getElementById('InvisbleForm').submit()"
<div style="display:none">
<form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="to_account" value="xxxxx">
</form>
</div>
</body>JPunyon: pourquoi voulez-vous quitter la vulnérabilité dans une nouvelle fonctionnalité
Vous ne créent pas plus d'insécurité. Vous êtes juste de pénaliser les développeurs qui veulent l'utiliser pour de bon. Toute personne qui souhaite utiliser cette fonctionnalité pour le mal (aka génial) pourrait simplement utiliser une autre méthode de le faire.
Conclusion
Je suis marquant la réponse de bobince que correcte car il a souligné le problème critique. Parce que XMLHTTPRequest permet à la poste, avec les identifiants de connexion ("cookies") pour le site de destination, et de lire les données envoyées à partir du site, avec l'envoi de la personnes des informations d'identification, vous pouvez orchestrer un peu de javascript qui permettrait de présenter une série de formes, y compris les formulaires de confirmation, complet avec toutes les clés aléatoires générés qui ont été mis en place pour tenter d'empêcher un XSRF. De cette façon, vous pouvez parcourir le site cible, comme une banque, et la banque du serveur web serait pas en mesure de dire que ce n'était pas seulement un utilisateur régulier de soumettre toutes ces formes.
- la modification de ces attaques parce qu'ils sont en réalité des attaques xsrf. xss lorsque vous injectez de script sur la légitime pages du site
- êtes-vous ici? Je veux éditer votre message pour le rendre plus clair. Dans certains cas, je ne suis pas entièrement comprendre votre anglais. Allez-vous revoir?
- Les modifications de regarder bon pour moi. Agréable de voir cette vieille question est toujours vivant et bien.
- J'ai décidé d'écrire ma propre réponse. Pouvez-vous, s'il vous plaît, prendre un coup d'oeil?
- "Parce que XMLHTTPRequest permet à la poste, avec les identifiants de connexion ("cookies") pour le site de destination, et de lire les données envoyées à partir du site". Ensuite attaquant, il suffit d'utiliser par exemple l'en-tête ("Access-Control-Allow-Origin: *') et peut lire les données envoyées à partir du site et soumettre des formulaires et etc. Ou misunderdstand quelque chose ?
Vous devez vous connecter pour publier un commentaire.
Parce que les requêtes AJAX sont (a) qui est envoyé avec les informations d'identification utilisateur, et (b) permettre à l'appelant de lire les données renvoyées.
C'est une combinaison de ces facteurs qui peuvent entraîner une vulnérabilité. Il y a des propositions pour ajouter un formulaire de cross-domain AJAX qui omet d'identification de l'utilisateur.
Aucune de ces méthodes de permettre à l'appelant de lire les données renvoyées.
(À l'exception des scripts où il est délibérément mis en place pour permettre que, pour les permis de la croix-domaine de la génération de scripts ou lorsque quelqu'un fait une terrible cock-up.)
Ce n'est pas une attaque XSS. C'est un cross-site request forgery (attaque XSRF). Il y a des façons de résoudre les attaques XSRF, tels que notamment un temps ou les jetons de vérifier que la demande est venue exprès de l'utilisateur et n'a pas été lancé à partir de l'attaquant code.
Si vous avez permis à la croix-domaine AJAX vous perdrez cette sauvegarde. L'attaquant de code pourrait demander à une page du site web des services bancaires, de lire toute autorisation pions, et les soumettre dans un deuxième requête AJAX pour effectuer le transfert. Et que serait être un cross-site scripting attaque.
Une différence importante entre le POSTE:
et Ajax est que après avoir fait un POST le navigateur va remplacer la page et après avoir fait l'appel Ajax - pas. Le résultat de la POSTE sera:
my-bank.comprend le contrôle. Aucune banque mettra en place un en un clic le transfert de.Le scénario de XSRF, si la croix de domaine Ajax serait autorisé, se présente comme suit:
www.bad-guy.com.my-bank.comdans d'autres instance du navigateur, l'attaque échoue.www.bad-guy.comfait un appel Ajax pourmy-bank.com.my-bank.comet il les envoie.www.bad-guy.compage.my-bank.comsi cela est nécessaire.L'essentiel est qu'aucun d'injection ou de n'importe quelle page de la falsification est nécessaire.
Une meilleure solution pourrait être de permettre l'appel lui-même, mais de ne pas envoyer des cookies. C'est une solution très simple qui ne nécessite pas de développement d'envergure. Dans de nombreux cas, appel Ajax va non protégés de l'emplacement et de ne pas envoyer les cookies ne sont pas une limitation.
De la SCRO (Croix-Origin Resource sharing) qui est en débat, maintenant, entre autres choses, parle de l'envoi/de ne pas l'envoi de cookies.
Bien, apparemment, vous n'êtes pas la seule personne qui se sent de cette façon...
http://www.google.com/search?q=xmlhttp+croix+site
EDIT: Il y a une discussion intéressante à partir de la recherche ci-dessus:
http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
Ressemble à des propositions sont en cours pour permettre à la croix-site xmlhttp demandes (IE 8, FF3, etc.), même si je souhaite qu'ils avaient été là quand j'ai écrit le code pour mes sites 🙂
Et puis il y a le problème de la compatibilité... Il faudra un certain temps avant de elle est omniprésente.
Lorsque vous envoyez une requête HTTP vers le serveur, les cookies placés par le serveur sont également envoyées par le navigateur au serveur. Le serveur utilise ces cookies pour établir le fait que l'utilisateur est connecté, etc.
Cela peut être exploité par un attaquant malveillant qui, avec l'aide de JavaScript, peuvent voler des informations ou d'effectuer non autorisée des commandes sur d'autres sites sans que l'utilisateur ne connaissant rien à ce sujet.
Par exemple, on pourrait demander à un utilisateur à visiter un site qui a le code JavaScript suivant (en supposant que jQuery):
Maintenant, si l'utilisateur a été vraiment connecté à la banque alors que le code ci-dessus a été exécuté, l'attaquant pourrait avoir transféré USD 10K pour le compte XXX.
Ce genre d'attaques sont appelés Cross Site Request Forgery (XSRF). Il n'y a plus d'infos à ce sujet sur Wikipédia.
C'est principalement pour cette raison, la même origine politique existe, et que les navigateurs ne vous permettent d'effectuer des XMLHttpRequests sur des domaines différents de l'origine.
Il y a quelques discussions sur pour réellement permettre à la croix-domaine XHR, mais nous devons voir si cela devient vraiment accepté.
C'est une préoccupation, car il peut être utilisé à de mauvaises fins, comme vous l'avez mentionné. Il peut également être utilisé avec une bonne intention, et pour cette raison, croix domaine des protocoles sont en cours d'élaboration.
Les deux plus grandes préoccupations sont lorsqu'il est utilisé en conjonction avec le cross-site scripting (XSS) et le cross-site request forgery (CSRF). Les deux sont de graves menaces (c'est pourquoi ils l'ont fait dans le top 10 OWASP et la SANS 25).
C'est XSS beaucoup trop d'applications sont vulnérables, et, si le navigateur modèles de sécurité n'empêchent pas les X-domaine de l'AJAX, ils ouvrent leurs utilisateurs à un formidable vecteur d'attaque.
Oui, mais ceux-ci vont envoyer un HTTP_REFERRER et (par d'autres moyens) peuvent être bloquées pour empêcher CSRF. Les appels AJAX peut usurper les en-têtes plus facilement et permettrait à d'autres moyens de contourner la traditionnelle CSRF protections.
Je pense à une autre chose qui sépare ce normal XSRF attaque, c'est que vous pouvez faire des trucs avec les données que vous obtenez de retour ainsi via javascript.
Je ne sais pas ce que le gros problème est? Avoir des appels AJAX envoyés vers d'autres domaines de sapins envoyé à votre application, puis transféré ailleurs avec les données filtrées, analyser les données renvoyées si vous en avez vraiment besoin, et le nourrir à l'utilisateur.
Sensible des requêtes AJAX? Clouer les entrants gourmands en cochant pour les en-têtes, le stockage de session de données en temps ou en filtrant les adresses IP entrant vers les sources de la confiance ou de vos applications.
Ce que j'avais personnellement, j'aime à voir dans l'avenir est solide comme le roc de sécurité sur toutes les demandes entrantes par défaut sur les serveurs web, frameworks et Cms, et ensuite de définir explicitement les ressources qui permettront d'analyser la demande provenant de sources extérieures.
Avec
<form>vous pouvez publier des données, mais vous ne pouvez pas le lire. AvecXHRvous pouvez faire les deux.Page comme
http://bank.example.com/display_my_passwordest protégé contre les XSRF (en supposant qu'il n'affiche et ne définit le mot de passe) et les cadres (ils ont le même-la politique de l'origine). Toutefois inter-domaine XHR serait une vulnérabilité.Vous tournez visiteurs non avertis en déni de service attaquants.
Aussi, Imaginez un cross site script qui vole toutes vos facebook trucs. Il ouvre un IFrame et accède à Facebook.com
Vous êtes déjà connecté à facebook (cookie) et il va se lit vos données et/ou les amis. Et ne plus méchants.