Compréhension du CORS

[Xenos]

Ca, c'est car la banque n'a pas fait durer la session trop longtemps. Imagine que mabanquemoisie.fr laisse la session de l'utilisateur active pendant 48h, alors monpirateadore.fr pourra envoyer les commandes qu'il veut à mabanquemoisie.fr, puisque le système de token dans les formulaires HTML ne servira plus à rien (le token peut être lu par monpirateadore.fr).

Se baser uniquement sur le domaine 1 pour savoir si je peux contacter le domaine 2 n'est pas sécurisé. Mais oui, ce serait encore mieux d'avoir à la fois un check de la part du domaine 1 ("domaine 1 autorise le client à contacter domaine 2") mais aussi de la part du domaine 2 ("domaine 2 accepte de répondre au client si c'est domaine 1 qui l'a demandé").

Y'a peut-être également une question à la fois de lourdeur (ajouter un header qui ne sera pas forcément utilisé) mais aussi de rétro-compatibilité (ajouter un header qui ne sera pas compris par les anciens navigateurs).
Mais à mon avis, si tu as une faille permettant d'injecter du javascript, t'es de toute façon dans la mouise, et la double-sécurité en question, tu t'en balancerais...

[KyleK]

#10 > Ouep je connais la technique, elle m'a rapporté pas mal quand j'étais jeune et sans morale. Mais il me semble qu'il n'y a rien (dans ce domaine) qu'on puisse faire avec CORS qu'on ne peut pas déjà faire sans. Récupérer les identifiants de session PHP en exploitant les failles des BBCodes trop laxistes reste la faille la plus simple. Pour ça pas besoin de CORS, du Dynamic Script Loading suffit largement et sur le DSL, il n'y a aucune vérification de cross-domain. D'où le fait que mon premier speech sur XSS dans le contexte est un peu HS (hors-sujet au cas où tu aurais compris hors-service).

[Xenos]

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...

[niahoo]

Oui oui ça me semble logique mais comme on n'est jamais sûr ça ne serait pas une sécurité de trop. Donc pour conclure je dirais que le must serait la double autorisation.

Kylek (qui s'est fait bannir par Akismet entre temps mdr) pour piquer les infos avec le DSL du coup tu balançais tout par l'URL ? J'ai eu fait ça aussi mais c'est assez galère à mettre en place. Si à l'époque j'avais connu AJAX et jQuery je me serais beaucoup plus amusé

[Xenos]

Les doubles sécurités présentent quand même un très gros problème dans le cas du développement en équipe: si le développeur D1 est en charge de la sécurité S1, et le développeur D2 en charge de la sécurité S2, alors D1 peut se dire "ouais, bon, mon S1 n'est pas super fiable, mais pas grave, y'a S2 derrière", et si D2 se dit pareil "ouais, bof, mon S2 est pas fiable, mais y'a S1 derrière", alors on risque d'avoir une faille de sécurité qui apparait.
L'idée est un peu similaire aux contrôles de qualités en usine: si 1 machine est capable de détecter et de stopper 100% des erreurs, alors elle est bien plus fiable que 2 machines en série qui détecteraient chacune 50% des erreurs (car on n'aurait alors pas 50%+50%=100% mais 50%*50%=25% d'erreurs non-détectées).
De plus, les doubles sécurités, qui créent des redondances, ne sont pas de bonnes solutions pour les programmes informatiques: si je découvre une faille et que je dois la corriger, quelle sécurité dois-je corriger? S1? S2? les deux?
De même pour la maintenance: 2 sécurités à maintenir, c'est pas génial...
Une sécurité est soit fiable à 100%, soit inutile, donc se dire "2 sécurités c'est mieux qu'une", statistiquement, d'accord (50%*50% c'est mieux que 50% seul), mais ce n'est pas la mentalité à adopter face aux problèmes de sécurités: si il existe une fuite, quelle que soit sa probabilité / taille, alors la sécurité est nulle.

Et pourquoi ce bannissement ? O.o

[niahoo]

le bannissement c'est l'antispam qui fait chier, ça m'est arrivé, Sephi m'a débloqué rapidos

Sinon pas d'accord. Là je vois pas ça comme une double sécurité, ce serait précisément la combinaison des deux qui ferait la sécurité.

C'est comme un échange de clés, chacun verrouille son côté du tunnel, chacun autorise mutuellement l'autre à communiquer avec lui.

Comme quand tu veux crypter un colis avec deux clés : A met son cadenas sur le colis et l'envoie à B. B met son cadenas sur le colis et le renvoie à A. A enlève son cadenas du colis et le renvoie à B, qui peut à son tour enlever le sien et ouvrir son colis. (hum bon rien à voir mais j'aime bien ce truc )

Moi je le verrais comme ça, et j'ajouterais qu'il n'y a pas de sécurité fiable à 100%, donc il n'y aurait que des sécurités inutiles ?

[Xenos]

Oui, mais là, c'est comme si A mettait 2 cadenas parce que l'un des deux peut venir de C (le visiteur qui a fait l'injection) et que A n'a pas été fichu de vérifier ce cadenas.
Cette "double sécurité" dont tu parles est normalement intrinsèquement dans le code javascript lui-même, puisque ce code javascript vient de ton serveur (de A). Le code javascript est le premier cadenas (si le code javascript ne demande pas le domaine B alors il ne se passe rien) et le domaine B, via Allow-Request-Origin (enfin, un header du genre j'ai oublié le nom) représente le 2nd cadenas.
Les deux cadenas sont bel et bien présents, inutile de rajouter une double sécurité du coté de A seul (oui, en un sens, ca serait encore plus sécurisé, mais ce serait aussi encore plus moche, imagine que ton colis arrive avec 4895 cadenas parce que A est parano et pas fichu de vérifier que ses cadenas n'ont pas une clef publique).

Les sécurités fiables à 100%, non, y'en n'a pas vraiment, mais toutes les normes et spécifications sont forcés de considérer que la source d'un message est intègre, sinon, ce serait tout simplement ingérable. Là, tu dis "si javascript est injecté? il faudrait mieux ajouter un header spécifique!". Ok, mais si le pirate peut changer le header? Il faudrait ajouter une clef RSA spécifique. Oui, mais si le pirate peut truquer la clef coté serveur et forcer le client à utiliser une clef précise? Il faudrait transporter la clef par chameau. Oui mais si le chameau a soif et qu'il s'arrête à une oasis tenue par le pirate?... etc. On peut aller très (bien trop!) loin si on considère que la source du message n'est pas fiable ni sécurisé. D'ailleurs, la sécurisation d'un message dont la source n'est pas fiable est totalement inutile. D'où le fait qu'il n'y ait pas ce second "verrou", qui est censé être déjà présent par l'absence de faille d'injection (même si l'injection est le N°1 de l'OWASP top 10 - 2013).

[niahoo]

Non mais le coup des cadenas ne s'applique pas, ici il n'y a qu'un aller. C'était juste pour dire qu'une sécurité faite par deux tiers ne doit pas être considéré comme deux sécurités à 50% mais comme une seule à 100% (disons 99.9999999)

Bien sûr il faudrait s'assurer qu'il n'y ait aucune injection, c'est la priorité. (de toute façon je fais confiance au W3C pour en savoir plus long que nous ^^).

Ici on n'est pas dans un modèle avec un facteur (pour les colis). C'est A qui offre la possibilité de faire partir une requête vers un domaine B. Si une injection tente d'envoyer des paquets à un domaine C, le navigateur l'interdit car C ne fait pas partie de la whitelist de A. (dans mon idée donc, pas dans CORS)

Je me place dans la position ou le pirate cherche à faire envoyer des informations à un tiers (son serveur perso). CORS permet de récupérer des informations depuis B si B autorise explicitement un domaine A à récupérer de l'info chez lui. Ces deux cas couvrent bien les termes d'un échange ou l'information va dans les deux sens. CORS seul empêche simplement les données de faire le chemin A <-- B mais pas A --> B

---

Mais le cas A --> B doit bien être couvert quelque part. J'ai regardé le code (très rapidement) dans l'article que j'ai posté, je n'ai pas trouvé.

[Xenos]

Là encore, je suis d'accord avec le raisonnement, mais pas avec l'hypothèse de base: on ne peut pas faire des specifications en se disant "et si le serveur a une injection?" car si le serveur respecte les spécifications précédentes, il n'a pas d'injection, donc l'hypothèse "et si..." est inutile.

Le cas A-->B est parfaitement couvert, car là encore, c'est le code javascript qui fait office de verrou. Ce code est envoyé par A (on s'en f** d'où il venait avant: c'est A qui envoie ce code, donc ce code vient de A), et ce code fait la requête vers B? c'est donc bien ce code qui fait office de verrou A-->B, et le CORS fait office de verrou A <-- B.

On ne peut pas faire des spécifications de sécurité en considérant "et si le domaine/serveur n'a pas respecté telle autre spécification?".

Accessoirement, pour l'histoire des tiers, comme l'a dit à juste titre l'un de nos intervenants de cours (un PDG d'une société de cuivre, en plein boum ces dernières années): "Le diable est dans les cloisons". Doubler une sécurité risque de générer une cloison (deux développeurs chacun sur sa sécurité), et il sera alors impossible de dire à qui revient la faute en cas de fuite, les deux développeurs vont se rejeter mutuellement la faute.

[niahoo]

ben oui parce que s'il y a un problème ton PDG il veut pouvoir virer quelqu'un, moi non. Moi je veux que le truc soit sûr et pour ça j'ai besoin de sécurités qui se complètent. Comment peux-tu être sûr qu'il ne peut pas y avoir d'injections sur ECLERD par exemple ?