24-07-2013, 11:51 PM
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).
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).