Introduits afin d'assouplir la Same Origin Policy pour permettre au Web 2.0 de donner sa pleine mesure, les Cross Origin Ressource Sharing (CORS) souffrent de spécifications pour le moins absconses et d'une dissymétrie d'implémentation particulièrement dommageable à leur bonne mise en œuvre. En conséquence, leur activation côté serveur conduit très souvent à la création de vulnérabilités exploitables susceptibles de faire le bonheur du pentesteur.
Cet article est découpé en deux parties : la première présente les CORS, la seconde s'attache à décrire les cas fréquents de mauvaises configurations débouchant sur des vulnérabilités exploitables, puis détaille plusieurs d'entre elles et suggère quelques contrôles et recommandations à destination des pentesteurs et de leurs clients.
1. Genèse des CORS
En 1995, le navigateur Netscape 2 introduit JavaScript, et avec lui la possibilité d'exécuter du code en provenance d'un site web. Il devient dès lors possible de réaliser des actions à l'insu de l'utilisateur et d'agir de manière silencieuse à sa place.
Un mécanisme nommé Same Origin Policy (désigné par l'acronyme SOP dans la suite de cet article) est alors implémenté au sein des agents. Ce mécanisme garantit l'impossibilité d'agir à l'insu d'un internaute sur un site (non vulnérable) en empêchant tout contenu provenant d'une origine A d'accéder au résultat d'une requête qu'il émettrait...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première