Compréhension du CORS

[niahoo]

Hello,

je suis en train de lire cet article concernant les CORS et il y a un truc que je ne pige pas :

Si je lis bien, c'est le domaine 2 (donc pas celui qui sert la page à l'origine) qui indique qu'il veut bien recevoir des requêtes du domaine 1.

Donc en gros, je suis un pirate, je veux pirater superjeu.com. Je vais sur superjeu.com, je balance du javascript via une faille dans le chat pour que les autres joueurs envoient des données à vilainpirate.ru.

vilainpirate.ru étant mon propre serveur, évidemment que je vais mettre des headers indiquant que je veux bien répondre à des requpetes venant de superjeu.com.

Pourquoi est-ce que ce n'est pas superjeu.com qui indique dans les headers de réponse qu'il autorise des requêtes ajax ou autre à partir vers superjeu-static.fr:8000 et surtout pas vers un autre domaine ?

[Xenos]

Salut,

Je comprends pareil que toi, mais à mon avis, le verrou de sécurité est ici:

je balance du javascript via une faille dans le chat

CORS présuppose que le site domain1.com est "bien fichu", et que l'on peut lui faire confiance.

[KyleK]

A vue de nez, ça a l'air d'une variante des failles XSS. Les sites sur lesquelles cette faille est exploitable sont légion, et s'il y a une forte fréquentation, en 15 minutes, on peut récolter des dizaines d'identifiants de session qu'il suffit alors de copier dans ses propres cookies pour se connecter aux comptes des autres joueurs sans mot de passe.

La parade consiste à filtrer tout ce que l'utilisateur peut écrire et qui sera affiché aux autres joueurs (livre d'or, chat, description de profil, messagerie privée, forum, etc.). Le filtrage le plus simple consiste à ne laisser aucune mise en forme (pas de HTML, pas de BBCode ni équivalent) que du texte filtré par exemple avec htmlspecialchars si on utilise PHP.

Dès lors qu'on propose du BBCode ou carrément un éditeur WYSIWYG, il faut être très prudent (attention au liens, aux contenus des images, etc.) tout ce qui permet de charger une ressource ou de faire un lien vers un autre domaine est potentiellement dangereux. Et bien sûr, il faut filtrer tous les contenus javascript (les onmachin="", les balise script, les href="javascript:...", ou href encodé en base64 etc.)

[niahoo]

Non les CORS ne sont pas des "variantes de failles", c'est une technologie permettant la collecte de ressources venant de domaines différents lors d'une requête récupérant une ressource originelle

[KyleK]

Je ne parlais pas de la techno en elle-même, évidemment, CORS n'est pas la faille, je n'ai jamais dit ça. C'est le piratage que tu as décrit qui s'apparente à de l'exploitation de faille XSS. Ce type de faille est indépendant de la techno qui "ouvre la faille". En l’occurrence il s'agit bien de ne pas laisser filtrer une info qui appartient à un domaine vers un autre domaine.

Et pour répondre à la question en fin de ton post : bah, c'est pas nous qui avons développé la fonctionnalité. C'est à peu près certain qu'il y avait un besoin spécifique auquel répond cette techno et qui nécessitait que le receveur précise l'acceptation par entête et non l'inverse.

Je dirai que ce cas de figure est le suivant :
"J'ai un domaine type encyclopédique ou annuaire : aucune donnée n'est privée et je souhaite proposer un accès facile à toutes mes ressources à n'importe qui." À moins qu'il ne s'agisse de rien d'autre que de proposer un moyen facile de proposer des pubs ciblées (rire diabolique).

À mon avis, la techno répond à ce besoin-là. Évidemment, ce n'est que mon humble avis et toute techno peut être détournée pour faire autre chose en considérant les risques que tu as mentionnés.

[niahoo]

J'suis d'accord. Mais j'ai l'impression que ça n'apporte rien : Mettons que je sois Wikipedia, je veux que tout le monde puisse avoir accès à mes ressources : C'est même pas la peine d'ajouter de header, puisque si le navigateur envoie une requête vers l'API ben je la sers sans me poser de question. Évidemment si je bloque les referer étranger ça marche pas mais puisque je souhaite partager je ne les bloque pas pis voilà.

et ça n'apporte pas de sécurité supplémentaire contre les XSS dans le schema que je décrivais.

Donc en gros même pour des pubs ou quoi, si on reçoit une requête on répond, basta. Donc je ne vois pas où est la valeur ajoutée ...

[archANJS]

http://www.w3.org/wiki/CORS#Use_Cases

The main motivation behind Cross-Origin Resource Sharing (CORS) was to remove the same origin restriction from various APIs so that resources can be shared among different origins (i.e. servers).

1. XMLHttpRequest (XHR)
2. Not tainting the canvas element (HTML)
3. Getting metadata out of media elements (HTML)
4. Server-Sent Events (EVENTSOURCE)
5. xml-stylesheet processing instruction (XMLSS)

J'imagine que dans ces cas bien spécifiques, les CORS ont leur utilité.

[KyleK]

Non j'avoue la sécurité XSS, c'est un peu HS, ça correspondait au vilainpirate.ru qui peut pomper de l'info. En même temps j'essaye de piger l'intérêt. Mais j'ai re-regardé le truc et j'ai peut-être une idée.

Avec un système comme ça, domain1 peut proposer un formulaire avec user/pass et envoyer user/pass à domain2 sans quitter la page. Si domain2 est d'accord de "recevoir" (et là du coup ça prend toute son importance que ce soit le receveur qui décide) une demande de domain1, il va effectuer la connexion sur son serveur avec le login reçu. Et du coup domain2 peut renvoyer d'éventuelles infos privées sur l'utilisateur.

Bon après, il faut oser mettre son login de domain2 sur un autre domaine, ça c'est pas gagné mais il y a sûrement des gens prêts à le faire pour peu qu'on leur propose des trucs du style : entrez votre user/pass du site mesphotos.com et notre site mesphotosencoremieux.com vous proposera les versions retouchées de vos photos avec des gros nez sur tous les visages.

Devant un service aussi intéressant l'utilisateur n'hésite pas. Et du coup mesphotosencoremieux.com doit demander la permission à mesphotos.com pour proposer ça.

La même chose pourrait être faite avec une API côté serveur, mais avec un système côté client, les serveurs économisent du travail.

Encore et toujours, je suis aussi perplexe et je laisse libre cour à mon imagination pour toutes ces hypothèses.

[Xenos]

Pourquoi est-ce que ce n'est pas superjeu.com qui indique dans les headers de réponse qu'il autorise des requêtes ajax ou autre à partir vers superjeu-static.fr:8000 et surtout pas vers un autre domaine ?

Je vais sur monpirateadore.fr et ce site envoie, dans les headers, que les domaines mabanqueamoi.fr peuvent être contactés via http/https. monpirateadore.com fait alors faire au client une requête vers mabanqueamoi.fr. Le client comprend donc, d'après le header, que la requpete est autorisée, et il la fait. monpirateadore.fr a donc accès à mes données bancaires.

Voilà pourquoi ce n'est pas le site visité seul qui dit "ok, la requête peut aller sur mabanqueamoi.fr", mais bien mabanqueamoi.fr qui dit "j'accepte de répondre si la demande vient de tel ou tel domaine".

[niahoo]

Oui ok pour la banque, mais ça ne marche que pour les gens qui mettraient le même mot de passe partout, y compris entre un vieux site de crack et un site de banque. Dans ce cas effectivement c'est important. Mais si ce n'est pas le même mot de passe, il n'aura accès à rien. Et encore, même avec le même mot de passe, l'authentification ne se fait pas via ajax, ou alors avec une clé. Et encore, si la banque est pas trop conne elle bloque les referer.

Mais bon, ok, là c'est une sécurité supplémentaire. Reste que dans l'autre sens ça me paraît nécessaire.

Kylek je ne comprends pas pourquoi tu dis que les XSS sont HS. Moi je pensais dans le cadre d'un jeu web : y a plein de types ici qui codent leur propre système de chat ou de forum, un régal pour piquer facilement les identifiants de l'alliance ennemie et de leur vider leurs ressources, si on peut piquer leurs identifiants comme tu le disais dans ton premier post.