La première partie de cet article parue dans le numéro précédent présentait la genèse et le fonctionnement des Cross Origin Resource Sharing (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. Conséquences du fonctionnement des CORS
L'implémentation de la SOP est laissée exclusivement aux bons soins de l'agent, c'est-à-dire à un nombre très restreint de programmes et d'équipes de développement. Ce qui n'est pas le cas des CORS dont la mise en oeuvre repose à la fois sur les agents, mais aussi sur les serveurs. Or il existe une variété pratiquement infinie de cas de figure côté serveur, et ce d'autant plus que contrairement à la SOP les CORS nécessitent une adaptation de leur fonctionnement au contexte, notamment du fait de l'impossibilité d'utiliser des jokers ou une liste d'origines dans l'en-tête Access-Control-Allow-Credentials.
Les CORS peuvent donc être implémentées à différents niveaux selon les choix de chaque entreprise : au sein d'un composant d'infrastructure (un WAF ou un proxy par exemple), mais aussi d'un serveur web, d'un serveur d'application, d'un framework ou d'une application serveur...
Comme nous avons pu le...
- 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
