24-07-2013, 08:31 PM
Il pourrait y avoir aussi, avec un système où c'est domaine 1 qui dit au client que domaine 2 peut être contacté, un détournement de la puissance de calcul du client, de sa bande passante, et une anonymisation des requêtes.
Si monpirateadore.fr veut aspirer tout le site toto.com, alors il peut dire au client, dans le header "monpirateadore.fr autorise le navigateur à contacter toto.fr"; ensuite, monpirateadore.fr fait ses requêtes via javascript et le navigateur les laisse passer (dans le cas où toto.com n'aurait pas son mot à dire). Ainsi, monpirateadore.fr peut accéder au contenu de toto.com sans que toto.com ne le sache: monpirateadore.fr est donc anonymisé pour toto.com par le biais du navigateur client: si monpirateadore.fr attaque toto.com, alors c'est le navigateur web du visiteur qui fera le travail et c'est donc ce visiteur qui verra la police à sa porte 1 semaine plus tard.
D'où la nécessitée de faire valider la requête par toto.com (mais cela ne réponds pas à "pourquoi les 2 domaines ne devraient-ils pas explicitement autoriser la requête cross-domain?"; je pense que la réponse à cette question c'est "implicitement, le domaine appelant autorise le client à aller voir le domaine appelé car les données envoyées par le domaine appelant, aka le javascript, sont considérées comme 'sûres' car elles émanent du domaine appelant"). En d'autres mots, ce n'est pas à la spécification de venir à ton secours si tu n'est pas capable d'empêcher les injections de code. En d'autres mots encore, les spécifications web considèrent que tout contenu venant de domaine1.fr est bien fournis par domaine1.fr ou est au moins validé par ce domaine. Donc, si ton codage moisi valide n'importe quoi, dont le javascript injecté, ce n'est pas la faute de la norme. Je ne sais pas si l'idée est claire...
Si monpirateadore.fr veut aspirer tout le site toto.com, alors il peut dire au client, dans le header "monpirateadore.fr autorise le navigateur à contacter toto.fr"; ensuite, monpirateadore.fr fait ses requêtes via javascript et le navigateur les laisse passer (dans le cas où toto.com n'aurait pas son mot à dire). Ainsi, monpirateadore.fr peut accéder au contenu de toto.com sans que toto.com ne le sache: monpirateadore.fr est donc anonymisé pour toto.com par le biais du navigateur client: si monpirateadore.fr attaque toto.com, alors c'est le navigateur web du visiteur qui fera le travail et c'est donc ce visiteur qui verra la police à sa porte 1 semaine plus tard.
D'où la nécessitée de faire valider la requête par toto.com (mais cela ne réponds pas à "pourquoi les 2 domaines ne devraient-ils pas explicitement autoriser la requête cross-domain?"; je pense que la réponse à cette question c'est "implicitement, le domaine appelant autorise le client à aller voir le domaine appelé car les données envoyées par le domaine appelant, aka le javascript, sont considérées comme 'sûres' car elles émanent du domaine appelant"). En d'autres mots, ce n'est pas à la spécification de venir à ton secours si tu n'est pas capable d'empêcher les injections de code. En d'autres mots encore, les spécifications web considèrent que tout contenu venant de domaine1.fr est bien fournis par domaine1.fr ou est au moins validé par ce domaine. Donc, si ton codage moisi valide n'importe quoi, dont le javascript injecté, ce n'est pas la faute de la norme. Je ne sais pas si l'idée est claire...