it-swarm.com.de

Pentest-Ergebnisse: Fragwürdiger CSRF-Angriff

Wir haben kürzlich eine unserer Webapps pentestieren lassen. Bis auf eine CSRF-Sicherheitslücke lief alles gut, und mit dieser Erkenntnis habe ich einen Knochen, mit dem ich mich befassen kann.

Einige Hintergrundinformationen: Wir verwenden ASP.NET MVC und verwenden unter anderem die darin integrierte Funktionalität CSRF-Schutz . Die Funktionsweise entspricht genau dem, was OWASP empfiehlt : indem sogenannte "Synchronizer-Token", eines in einem HTTP-Cookie und eines in einer versteckten Eingabe mit dem Namen __RequestVerificationToken, Eingefügt werden:

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

Wir führen auch regelmäßige Acunetix-Scans durch, und diese Scans haben keine CSRF-ungeschützten Formen gefunden.

Nun behaupten die Pentester, dass sie unseren CSRF-Schutz mit dem folgenden Code "verletzen" konnten:

<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>

Die Aufnahme des Feldes __RequestVerificationToken Stört mich am meisten: Für mich ist es vergleichbar mit der Behauptung, dass ein Angreifer Millionen Dollar von meinem Bankkonto überwiesen hat, weil ich ihm freiwillig mein iPhone zum Spielen gegeben habe, und er Ich habe das Einmalpasswort gesehen, das meine Bank per SMS gesendet hat.

Ich stelle mir vor, dass dieser Angriff möglicherweise nur funktionieren könnte, wenn wir kein HTTPS verwenden, für XSS anfällig sind, nicht nur HTTP-Cookies verwenden und eine Richtlinie mit demselben Ursprung fahrlässig anwenden. Nichts davon ist wahr, da keine dieser Schwachstellen von Pentestern oder Acunetix gemeldet wurde.

Die Frage ist also: irre ich mich und dies ist eine legitime CSRF-Sicherheitslücke oder nicht?

27
Anton Gogolev

Dies scheint keine CSRF-Sicherheitslücke zu sein.

Wenn ein Angreifer ein CSRF-Token kennen muss, handelt es sich nicht um einen Angriff. Und Ihre Herangehensweise an CSRf scheint richtig zu sein.

Probleme, bei denen das CSRF-Token verloren geht, können zwar zu einem CSRF-Angriff führen, aber dann ist das Problem nicht der falsche CSRF-Schutz, sondern diese Probleme (XSS, Verschlüsselung, CSRF-Token in URL usw.).

Trotzdem würde ich den Tester um Klarstellung bitten. Wer weiß, vielleicht funktioniert der Angriff immer mit diesem bestimmten Token, weil er irgendwo fest codiert ist oder weil die Sonderzeichen ein Problem für Ihre Anwendung verursachen. Oder es ist möglich, ein Token eines anderen Benutzers zu verwenden, oder die Token-Prüfung funktioniert überhaupt nicht und akzeptiert beliebige Token. Der Bericht hätte mehr Details enthalten sollen, daher würde ich diesbezüglich beim Tester nachfragen.

46
tim

Es ist in der Tat seltsam, dass die __RequestVerificationToken ist im Proof of Concept enthalten, da ein Angreifer normalerweise den Wert dieses Tokens nicht kennt.

Die Seite kann jedoch weiterhin für CSRF anfällig sein, wenn __RequestVerificationToken ist nicht korrekt an die Sitzung gebunden. Wenn der Wert im Proof of Concept, _e-upIZFx7i0YyzrVd[...], funktioniert für alle, Sie sind anfällig für CSRF. Wenn es nur für den Benutzer funktioniert, unter dem der Pentester angemeldet war, sind Sie nicht anfällig für CSRF.

Da Sie den standardmäßigen .NET CRSF-Schutz verwenden, würde ich davon ausgehen, dass dieser korrekt implementiert ist und der Pentester einen Fehler gemacht hat.

12
Sjoerd

Wenn __RequestVerificationToken auf der Serverseite nicht validiert ist und für jede einzelne Anforderung und jeden anderen Benutzer als yes funktioniert, ist Ihre Anwendung für CSRF anfällig.

2
Michal Koczwara