web-dev-qa-db-fra.com

Comprendre XMLHttpRequest sur CORS (responseText)

Pour un projet, je regarde divers éléments HTML5 et Javascript et la sécurité autour d'eux et j'essaie de me familiariser avec CORS tout de suite.

Sur la base de mes tests, si je supprime ..

<?php
 header("Access-Control-Allow-Origin: *"); 
 header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
 ?>

..de la page qui tente d'accéder, je vois ce qui suit dans le journal de la console sur Chrome:

XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.

Je comprends que c'est correct, cependant Wireshark affiche HTTP/1.1 200 OK dans le retour et dans les données montre la source de la page demandée. Donc, est-ce seulement le navigateur et Javascript qui empêche ResponseText d'être utilisé de manière substantielle même s'il est réellement transféré?

Le code est comme ci-dessous:

  function makeXMLRequest() {
  xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState==4) {
        alert(xmlhttp.responseText);
    }
}
xmlhttp.open("GET","http://www.bla.com/index.php",true);
xmlhttp.send();
}

Merci d'avance.

javascriptxmlhttprequestcors
16
AreYouSure

Pour un verbe HTTP "simple" comme GET ou POST, oui, la page entière est récupérée, puis le navigateur décide si JavaScript doit utiliser le contenu ou non. Le serveur n'a pas besoin de savoir d'où viennent les demandes; c'est le travail du navigateur d'inspecter la réponse du serveur et de déterminer si JS est autorisé à voir le contenu.

Pour un verbe HTTP "non simple" comme PUT ou DELETE, le navigateur émet une "demande de contrôle en amont" à l'aide d'une demande OPTIONS. Dans ce cas, le navigateur vérifie d'abord si le domaine et le verbe sont pris en charge, en vérifiant Access-Control-Allow-Origin et Access-Control-Allow-Methods, respectivement. (Voir le " Gestion d'une demande pas si simple " sur la page CORS de HTML5 Rocks pour plus d'informations.) La réponse de contrôle en amont répertorie également les en-têtes non simples autorisés, inclus dans Access-Control-Allow-Headers.

En effet, autoriser un client à envoyer une demande DELETE au serveur peut être très mauvais, même si JavaScript ne parvient jamais à voir le résultat interdomaine - encore une fois, n'oubliez pas que le serveur n'est généralement pas tenu de vérifier que la demande provient d'un domaine légitime (bien qu'il puisse le faire en utilisant l'en-tête Origin de la requête).

33
apsillers

Donc, est-ce seulement le navigateur et Javascript qui empêche ResponseText d'être utilisé de manière substantielle même s'il est réellement transféré?

Oui. Vous pouvez faire toute demande que vous souhaitez avec JS.

C'est l'accès aux données que la même politique d'origine empêche.

Les requêtes qui font des choses malveillantes (telles que "POST http://bank.example/give/money?to=attacker" ou "POST http://forum.example.com/post?message=spamspamspamspam") sont appelés attaques CSRF et doivent être défendus par le serveur.

6
Quentin