Je veux savoir si un appel HTTP_REQUEST entrant d'un site web tiers provient de la liste de domaines que j'ai définie.
Je sais que HTTP_REFERER peut être utilisé pour savoir où se trouve le domaine du tiers, mais ce n'est pas assez sûr. Les gens peuvent l'usurper ou utiliser Telnet pour le falsifier.
Qu'en est-il de HTTP_ORIGIN ? Est-il envoyé par tous les navigateurs ? Est-il sécurisé ?
Par ailleurs, peut-on falsifier le REMOTE_ADDR dans un appel HTTP_REQUEST ?
HTTP_ORIGIN est un moyen de se protéger contre les CSRF (Cross Site Request Forgery). Actuellement, il n'est implémenté que par Chrome (depuis novembre 2011). J'ai testé Firefox et Opera, mais ils ont échoué.
Son nom dans l'en-tête de la requête est Origin . Sur le serveur, dans mon script, je le vois comme suit HTTP_ORIGIN en el $_SERVER tableau. Cet en-tête n'est envoyé que dans certains cas, lorsqu'une protection contre le CSRF est nécessaire (seul POST devrait suffire). Voici la liste de toutes les requêtes pour lesquelles cet en-tête est activé ou non :
https://wiki.mozilla.org/Security/Origin
Les Origin n'est mis en œuvre que dans Chrome, malheureusement. Il a été annoncé pour la première fois en janvier 2010 sur le blog de Google Chrome :
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
Protection CSRF via l'en-tête d'origine
L'en-tête Origin est une nouvelle fonctionnalité HTML5 qui vous aide à défendre votre site contre les attaques de type "cross-site request forgery" (CSRF). Dans une attaque CSRF, un site web malveillant, par exemple attacker.com, demande au navigateur de l'utilisateur d'envoyer une requête HTTP à un serveur cible, par exemple example.com, qui induit le serveur example.com en erreur et l'amène à effectuer une action. Par exemple, si example.com est un fournisseur de webmail, l'attaque CSRF peut amener example.com à transférer un message électronique à l'attaquant.
L'en-tête Origin aide les sites à se défendre contre les attaques CSRF en identifiant le site web qui a généré la requête. Dans l'exemple ci-dessus, example.com peut voir que la demande provient du site web malveillant parce que l'en-tête Origin contient la valeur http://attacker.com . Pour utiliser l'en-tête Origin comme moyen de défense contre le CSRF, un site ne doit modifier l'état qu'en réponse à des requêtes qui (1) n'ont pas d'en-tête Origin ou (2) ont un en-tête Origin avec une valeur sur liste blanche.
Je ne fais qu'implémenter la protection CSRF dans mon PHP script, j'utilise personnellement Chrome, c'est donc suffisant pour moi, j'espère que d'autres navigateurs rattraperont Chrome bientôt.
Ce qui est amusant, c'est que Mozilla a inventé cette fonction de sécurité, comme vous pouvez le constater en lisant de nombreuses documentations à ce sujet Origin sur son site web, mais ils n'ont toujours pas eu le temps de le mettre en œuvre ;-)
HTTP_ORIGIN semble ne contenir que des protocol y domain sans barre oblique à la fin : "http://www.example.com" - même si vous soumettez le formulaire à partir de "http://www.example.com/myform/".
Une protection simple contre CSRF en PHP script :
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (isset($_SERVER['HTTP_ORIGIN'])) {
$address = 'http://'.$_SERVER['SERVER_NAME'];
if (strpos($address, $_SERVER['HTTP_ORIGIN']) !== 0) {
exit('CSRF protection in POST request: detected invalid Origin header: '.$_SERVER['HTTP_ORIGIN']);
}
}
}Ce script pourrait encore être mis à jour pour prendre en charge un PORT autre que 80 (Origin contient le port lorsqu'il est différent de 80), les connexions HTTPS, et la soumission des formulaires à partir de différents sous-domaines (ex. sub.example.com => envoi de la demande à www.example.com ).
Les gens ici pensent tout de travers - la norme "CORS" n'a pas pour but d'empêcher le piratage du serveur, même si elle aide à cela en plus de ce qu'elle fait. L'objectif est de permettre au "BROWSER" d'avoir un moyen d'alléger les requêtes qui vont à l'encontre de la politique de la même origine. Si le client et le serveur sont sur la même longueur d'onde, le "CLIENT" peut décider d'autoriser ou non la requête.
Il est évident qu'en faisant participer le serveur à la décision, vous contribuez au processus de sécurité.
Mais il ne protège pas le serveur contre les accès non autorisés - c'est à cela que servent les mots de passe et les cookies.
Les client peut être (comme quelqu'un l'a mentionné) un outil telnet, où chaque chose créée est fausse.
Mais l'un des arguments de vente de Chrome, de FF, etc., est qu'ils vous aideront en ne permettant pas à Javascript de sortir du même bac à sable d'origine, ce qui signifie que la seule chose par défaut qui peut être compromise est ce qui se trouve sur le site web de l'"attaquant". Ou d'autres sites qui décident de ne pas être sécurisés.
CORS est la technologie qui vous permet de dire - hé, je veux que les utilisateurs puissent consommer mon service sophistiqué à partir du javascript sur cet autre site qu'ils utilisent. Je vais donc ajouter ce site à mes exceptions. Cela signifie que vous aidez vos utilisateurs autorisés à percer une brèche dans la sécurité de leur navigateur pour ce site en particulier. Une faille qu'un pirate informatique peut exploiter. D'où le soin que vous avez apporté à la mise en place du service, n'est-ce pas ?
Cela signifie que tout site qui n'a pas de CORS est par défaut protégé contre le Cross Site Scripting à partir d'un navigateur conforme (sauf en cas de bogues et de piratages, bien sûr). Le navigateur demandera si ce service veut participer au javascript du site d'origine, et si le site croisé répond "Je ne sais rien de ce foutu site", alors le moteur javascript du navigateur fermera la connexion et videra les données.
En résumé, CORS ne vous aide pas à sécuriser les choses. Il vous aide à créer un trou dans la capacité de votre navigateur à sécuriser l'utilisateur. Mais avec un peu de chance, d'une manière gérée et seulement pour des sites particuliers
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
