Comment les serveurs Web appliquent-ils la politique de même origine?

Je plonge plus profondément dans le développement d'API RESTful et j'ai jusqu'à présent travaillé avec quelques frameworks différents pour y parvenir. Bien sûr, j'ai rencontré la même politique d'origine, et maintenant je me demande comment les serveurs Web (plutôt que les navigateurs Web) l'appliquent. D'après ce que je comprends, une application semble se produire à la fin du navigateur (par exemple, honorer un en-tête Access-Control-Allow-Origin reçu d'un serveur). Mais qu'en est-il du serveur?

Par exemple, supposons qu'un serveur Web héberge une application Web Javascript qui accède à une API, également hébergée sur ce serveur. Je suppose que le serveur appliquerait la même politique d'origine --- afin que seul le javascript hébergé sur ce serveur soit autorisé à accéder à l'API. Cela empêcherait quelqu'un d'autre d'écrire un client javascript pour cette API et de l'héberger sur un autre site, non? Alors, comment un serveur Web pourrait-il arrêter un client malveillant qui essaierait de faire des requêtes AJAX à ses points de terminaison API tout en prétendant exécuter un javascript provenant de ce même serveur Web? Quelle est la façon dont les serveurs les plus populaires (Apache, nginx) protègent contre ce type d'attaque? Ou est-ce que ma compréhension de cela est hors de propos?

Ou la politique d'origine croisée n'est-elle appliquée que du côté client?

La même politique d'origine est une restriction entièrement basée sur le client et est principalement conçue pour protéger les utilisateurs , pas les services . Tous ou la plupart des navigateurs incluent un commutateur de ligne de commande ou une option de configuration pour le désactiver. Les SOP sont comme des ceintures de sécurité dans une voiture: elles protègent le pilote dans la voiture, mais n'importe qui peut librement choisir de ne pas les utiliser. Ne vous attendez certainement pas à ce que la ceinture de sécurité d'une personne l'empêche de sortir de sa voiture et de vous attaquer (ou d'accéder à votre service Web).

Supposons que j'écris un programme qui accède à votre service Web. C'est juste un programme qui envoie des messages TCP qui incluent des requêtes HTTP. Vous demandez un mécanisme côté serveur pour faire la distinction entre les demandes faites par mon programme (qui peut envoyer n'importe quoi) et les demandes faites par un navigateur qui a une page chargée à partir d'une origine autorisée. Cela ne peut tout simplement pas être fait; mon programme peut toujours envoyer une demande identique à celle formée par une page Web.

La politique de même origine a été inventée car elle empêche le code d'un site Web d'accéder au contenu restreint aux informations d'identification sur un autre site. Les demandes Ajax sont envoyées par défaut avec tous les cookies d'authentification accordés par le site cible. Par exemple, supposons que je charge accidentellement http://evil.com/, ce qui envoie une demande de http://mail.google.com/. Si le SOP n'était pas en place et que j'étais connecté à Gmail, le script à evil.compouvait voir ma boîte de réception. Si le site à evil.comsouhaite charger mail.google.comsans mes cookies, il peut simplement utiliser un serveur proxy; le contenu public de mail.google.comn'est pas un secret (mais le contenu de mail.google.comlorsqu'il est consulté avec mes cookies est un secret).

La stratégie de même origine est appliquée côté client. Si le navigateur prend en charge CORS , le serveur peut renvoyer des en-têtes qui indiquent au navigateur de faire des exceptions à la politique de même origine. Par exemple, envoyer l'en-tête

 Access-Control-Allow-Origin: www.example.com

indiquerait au navigateur d'autoriser les demandes d'origine croisée de www.example.com.

 Access-Control-Allow-Origin: *

indique au navigateur d'autoriser toutes les demandes d'origine croisée vers cette ressource.

Les serveurs Web empêchent généralement les attaques de ce type en vérifiant la ligne (tristement mal orthographiée) Refererdans l'en-tête HTTP, pour s'assurer qu'une demande provient d'une page de leur propre site. Il n'y a pas de bon moyen de se prémunir contre un client malveillant, mais ce n'est pas ainsi que fonctionnent les attaques XSRF.

Le client n'est pas malveillant; c'est généralement un utilisateur ordinaire qui a été trompé par un tiers malveillant pour ouvrir un document qui fait silencieusement une demande HTTP en utilisant les cookies stockés du client. Donc, si le serveur peut vérifier via la Refererque la requête HTTP provient de gmail.com, et non de MyAwesomeWebsite.com, il peut arrêter l'attaque.

Comment les serveurs Web appliquent-ils la politique de même origine?

En bref, ce n'est pas le cas, comme l'ont souligné Apsillers et Dirk .
Une raison importante est que l'en-tête ACAO protège les serveurs eux-mêmes contre les attaques DDOS rampantes, déni de service distribué .

Qui:

L'ACAO en tant qu'en-tête de réponse HTTP est destiné à être interprété par le client Web, fonctionnant sous l'hypothèse que la majorité des utilisateurs d'Internet humains naviguent sur le Web via les principaux fournisseurs de navigateurs qui adhèrent et mettent en œuvre le projet recommandé par le W3C . Après tout, la plupart d'entre eux devraient bénéficier d'un Internet rapide et accessible.

Comment:

Sinon, n'importe qui pourrait simplement copier et coller quelques lignes de code javascript dans un site Web malveillant qui exécute une simple boucle, ce qui fait une demande Ajax GET ou POST vers un domaine étranger. Sans interaction avec l'utilisateur et sans possibilité de multithread.

C'est pourquoi vous devez vous inscrire pour accéder à un site multi-origine, via l'en-tête HTTP ACAO . Vous, l'utilisateur, pouvez accéder à tout moment audit site via une interaction adaptée à l'utilisateur, c'est-à-dire un lien Internet. Tout comme vous pouvez copier ou coller du contenu à partir de ou vers votre presse-papiers, mais pas d'autre moyen - plugins mis à part.

Futur:

À ce stade, tenez compte des directives du fabricant du navigateur Web:

• suppression du plugin par défaut , comme étape vers un environnement entièrement en bac à sable et
• suppression de l'option utilisateur pour désactiver javascript

Les restrictions de sécurité peuvent être décemment établies en utilisant une combinaison de TSL 2/3, des ID de session forts, des TAN, une authentification à deux facteurs, etc.

"Google" a ceci à montrer et à dire sur DDOS

Enfin, tout le monde est libre de mandater n'importe quel contenu Web et d'ajouter un en-tête ACAO souhaité pour accéder au contenu intersite mandaté. De même, ce proxy est alors aussi ouvert à une attaque DDOS que le paramètre ACAO le permet. En fait, je ne connais aucune offre de service public gratuite. S'il vous plait corrigez moi si je me trompe.

Comme d'autres l'ont dit, c'est au client. Mais le serveur devra peut-être gérer XSS, qui contourne SOP.

Supopse votre serveur permet aux utilisateurs de télécharger du contenu, qui s'affiche lorsque d'autres utilisateurs parcourent votre site. Cette page est un bon exemple - je viens de télécharger du contenu et il vous est affiché.
Si mon contenu contient la <script>balise et que le serveur la copie simplement dans le code HTML qu'il génère, le script que j'ai téléchargé s'exécutera.
Étant donné que le script a été trouvé en HTML à partir de votre fichier, il dispose de toutes les autorisations du script de votre site. Il peut, par exemple, voter contre cette réponse. Et c'est pourquoi cette réponse a autant de votes positifs.

Un bon serveur Web (comme, hélas, celui que StackExchange utilise) ne permettra pas que cela se produise. Il peut supprimer la <script>balise, ou y échapper, donc il sera vu mais pas exécuté (avertissement - cette réponse est loin d'être une recette fiable pour empêcher XSS).

C'est donc le côté client qui applique le SOP, mais dans certains cas, le serveur devrait fonctionner pour éviter de le contourner.