web-dev-qa-db-fra.com

Pentest Results: Attaque CSRF douteuse

Nous avons récemment fait tester l'une de nos applications Web. Tout s'est bien passé, à l'exception d'une vulnérabilité CSRF, et c'est cette constatation que j'ai un os à choisir.

Quelques informations: nous utilisons ASP.NET MVC et, entre autres, nous utilisons la fonctionnalité protection CSRF intégrée. La façon dont cela fonctionne est strictement conforme à ce que OWASP recommande : en incluant les soi-disant "jetons de synchronisation", un dans un cookie HTTP et un autre dans une entrée cachée nommée __RequestVerificationToken:

<form action="/Home/Test" method="post">
  <input name="__RequestVerificationToken" type="hidden" 
    value="6fGBtLZmVBZ59oUad1Fr33BuPxANKY9q3Srr5y[...]" />    
  <input type="submit" value="Submit" />
</form>

Nous effectuons également des analyses Acunetix régulières, et les analyses n'ont jamais trouvé de formes non protégées CSRF.

Maintenant, ce que les pentesters prétendent, c'est qu'ils ont pu "violer" notre protection CSRF avec le code suivant:

<html>
  <body>
    <form action="https://our.site/support/discussions/new" method="POST">
      <input type="hidden" name="subject" value="Subject" />
      <input type="hidden" name="content" value="Content" />

      <input type="hidden" name="__RequestVerificationToken" 
        value="_e-upIZFx7i0YyzrVd[...]" />

      <input type="submit" value="Submit Request" />
    </form>
  </body>
</html>

L'inclusion de __RequestVerificationToken c'est ce qui me dérange le plus: pour moi, cela revient à affirmer qu'un attaquant a transféré des milliards de dollars de mon compte bancaire parce que je lui ai volontairement donné mon iPhone pour jouer, et il a vu le mot de passe à usage unique que mon banque a envoyé un SMS.

J'imagine que la seule façon dont cette attaque pourrait potentiellement fonctionner est si nous n'utilisions pas HTTPS, étions vulnérables à XSS, utilisions des cookies non HTTP uniquement et faisions preuve de négligence avec une même politique d'origine. Rien de tout cela n'est vrai, car aucune de ces vulnérabilités n'a été signalée par les pentesters ou Acunetix.

La question est donc: je me trompe et c'est une vulnérabilité CSRF légitime ou n'est-ce pas?

penetration-testcsrf
27
Anton Gogolev

Cela ne semble pas être une vulnérabilité CSRF.

Si un attaquant a besoin de connaître un jeton CSRF, ce n'est pas une attaque. Et votre approche de la CSRf semble être correcte.

Les problèmes qui fuient le jeton CSRF peuvent en effet entraîner une attaque CSRF, mais le problème n'est pas une protection CSRF incorrecte, mais ces problèmes (XSS, cryptage, jeton CSRF dans l'URL, etc.).

Je voudrais quand même demander des éclaircissements au testeur. Qui sait, peut-être que l'attaque fonctionne toujours avec ce jeton spécifique, car il est codé en dur quelque part, ou parce que les caractères spéciaux causent une sorte de problème pour votre application. Ou peut-être qu'il est possible d'utiliser un jeton d'un autre utilisateur, ou peut-être que la vérification des jetons ne fonctionne tout simplement pas et accepte des jetons arbitraires. Le rapport aurait dû contenir plus de détails, donc je reviendrais avec le testeur à ce sujet.

46
tim

Il est en effet étrange que le __RequestVerificationToken est inclus dans la preuve de concept, car normalement un attaquant ne connaîtrait pas la valeur de ce jeton.

Cependant, la page peut toujours être vulnérable à CSRF si le __RequestVerificationToken n'est pas correctement lié à la session. Si la valeur dans la preuve de concept, _e-upIZFx7i0YyzrVd[...], fonctionne pour tout le monde, vous êtes vulnérable au CSRF. Si cela ne fonctionne que pour l'utilisateur sous lequel le pentester était connecté, vous n'êtes pas vulnérable à CSRF.

Puisque vous utilisez la protection .NET CRSF par défaut, je suppose que celle-ci est correctement mise en œuvre et que le pentester a fait une erreur.

12
Sjoerd

Si __RequestVerificationToken n'est pas validé côté serveur et s'il fonctionne pour chaque requête et utilisateur différent, oui, votre application est vulnérable à CSRF.

2
Michal Koczwara