Access-control-allow-Origin: * avec un jeton au porteur
Lors du test d'une application d'une seule page, j'ai identifié que les points de terminaison REST renvoient des en-têtes CORS qui permettent un accès entre domaines:
access-control-allow-credentials: true
access-control-allow-methods: GET, POST, DELETE, PUT
access-control-allow-Origin: *
Ces points finaux traitent des données confidentielles, donc ma première réaction à cela est d'augmenter la vulnérabilité à haut risque.
Cependant, lorsque j'ai tenté d'exploiter le problème, j'ai constaté que je ne pouvais pas. Le site utilise un jeton au porteur dans l'en-tête d'autorisation au lieu d'un cookie de session. Bien qu'il soit possible de faire des demandes interdomaines, il n'est pas possible de joindre l'en-tête requis.
Quels sont les risques avec ce modèle? Est-ce une façon sensée de faire les choses?
Il y a quelques choses qui signifieront que l'exploitation est peu probable.
Commencer avec
access-control-allow-credentials: true
access-control-allow-Origin: *
est une combinaison non valide :
Remarque importante: lors de la réponse à une demande d'informations d'identification, le serveur doit spécifier un domaine et ne peut pas utiliser le joker. L'exemple ci-dessus échouerait si l'en-tête était joker comme: Access-Control-Allow-Origin: *. Étant donné que Access-Control-Allow-Origin mentionne explicitement
http://foo.example, le contenu connaissant les informations d'identification est renvoyé au contenu Web appelant.
Une autre chose est que l'en-tête d'autorisation n'est pas un simple en-tête , il faudrait donc un contrôle en amont qui se traduit par un Access-Control-Allow-Headers réponse renvoyant cet en-tête. Le serveur ne renvoyant pas cela empêcherait également toute attaque CSRF, car le pré-vol la bloquera.
À moins qu'il n'autorise l'en-tête, il n'est généralement pas possible d'ajouter un domaine croisé d'en-tête personnalisé sauf si vous tentez un exploit avec Flash qui fonctionnait auparavant sur certains navigateurs.
Quels sont les risques avec ce modèle? Est-ce une façon sensée de faire les choses?
Comme il n'est pas valide de spécifier cette combinaison d'en-têtes, ce n'est en effet pas une manière sensée de faire les choses. Il peut y avoir un navigateur étrange qui le permettrait et le site serait vulnérable (si une victime potentielle l'utilisait). Autoriser toutes les origines mais pas les requêtes avec accréditation permet le navigateur de la victime doit être utilisé comme une sorte de proxy afin d'atteindre des ressources autrement inaccessibles. Cependant, comme l'en-tête du support ne peut pas être attaché (sans un exploit Flash) et être autorisé via Access-Control-Allow-Headers, Je ne dirais pas que c'est un risque élevé. De plus, comme l'attaquant n'a pas le jeton de porteur de sa victime, toute demande interdomaine qui serait faite serait soumise à la session de l'attaquant plutôt qu'à celle de sa victime.
Je soulignerais probablement comme un élément consultatif qu'ils devraient vérifier que leurs en-têtes CORS correspondent à leur intention.