FixVibe
Covered by FixVibehigh

CORS Mauvaise configuration : risques de politiques trop permissives

Le partage de ressources entre origines croisées (CORS) est un mécanisme de navigateur conçu pour assouplir la politique de même origine (SOP). Bien que nécessaire pour les applications Web modernes, une mise en œuvre inappropriée (par exemple, faire écho à l'en-tête Origin du demandeur ou ajouter l'origine « nulle » à la liste blanche) peut permettre à des sites malveillants d'exfiltrer les données privées des utilisateurs.

CWE-942

##Impact Un attaquant peut voler des données sensibles et authentifiées aux utilisateurs d'une application vulnérable [S2]. Si un utilisateur visite un site Web malveillant alors qu'il est connecté à l'application vulnérable, le site malveillant peut envoyer des requêtes d'origine croisée au API de l'application et lire les réponses [S1][S2]. Cela peut conduire au vol d'informations privées, notamment des profils d'utilisateurs, des jetons CSRF ou des messages privés [S2].

Cause première

CORS est un mécanisme basé sur un en-tête HTTP qui permet aux serveurs de spécifier quelles origines (domaine, schéma ou port) sont autorisées à charger les ressources [S1]. Les vulnérabilités surviennent généralement lorsque la politique CORS d'un serveur est trop flexible ou mal mise en œuvre. [S2] :

  • En-tête d'origine réfléchie : Certains serveurs lisent l'en-tête Origin à partir d'une requête client et le renvoient dans l'en-tête de réponse Access-Control-Allow-Origin (ACAO) [S2]. Cela permet effectivement à n’importe quel site Web d’accéder à la ressource [S2].
  • Caractères génériques mal configurés : Bien que le caractère générique * permette à n'importe quelle origine d'accéder à une ressource, il ne peut pas être utilisé pour les demandes nécessitant des informations d'identification (comme les cookies ou les en-têtes d'autorisation) [S3]. Les développeurs tentent souvent de contourner ce problème en générant dynamiquement l'en-tête ACAO basé sur la requête [S2].
  • Liste blanche « null » : Certaines applications mettent sur liste blanche l'origine null, qui peut être déclenchée par des requêtes redirigées ou des fichiers locaux, permettant à des sites malveillants de se faire passer pour une origine null pour accéder à [S2][S3].
  • Erreurs d'analyse : Des erreurs dans la correspondance d'expression régulière ou de chaîne lors de la validation de l'en-tête Origin peuvent permettre aux attaquants d'utiliser des domaines tels que trusted-domain.com.attacker.com [S2].

Il est important de noter que CORS n'est pas une protection contre la falsification de requêtes intersites (CSRF) [S2].

Réparations concrètes

  • Utilisez une liste blanche statique : Évitez de générer dynamiquement l'en-tête Access-Control-Allow-Origin à partir de l'en-tête Origin [S2] de la requête. Au lieu de cela, comparez l'origine de la demande à une liste codée en dur de domaines de confiance [S3].
  • Évitez l'origine « nulle » : N'incluez jamais null dans votre liste blanche d'origines autorisées [S2].
  • Restreindre les informations d'identification : Ne définissez Access-Control-Allow-Credentials: true que si cela est absolument nécessaire pour l'interaction d'origine croisée spécifique [S3].
  • Utilisez une validation appropriée : Si vous devez prendre en charge plusieurs origines, assurez-vous que la logique de validation de l'en-tête Origin est robuste et ne peut pas être contournée par des sous-domaines ou des domaines d'apparence similaire [S2].

Comment FixVibe le teste

FixVibe l'inclut désormais en tant que contrôle actif sécurisé. Après vérification du domaine, active.cors envoie des requêtes API de même origine avec une origine d'attaquant synthétique et examine les en-têtes de réponse CORS. Il signale des origines arbitraires, un CORS authentifié par caractère générique et un CORS grand ouvert sur les points de terminaison API non publics tout en évitant le bruit des actifs publics.