2014-09-24 4 views
5

Ich habe ASP ARF-Token in meiner MVC3-Webanwendung implementiert und in die Funktionsweise des CSRF-Exploits eingelesen und wie ARF-Tokens dagegen vorgehen. Jetzt habe ich mich gefragt, ob 'Hacker' die ARF-Prüfung nicht umgehen konnten, indem sie einen zusätzlichen Schritt benutzten. Der normale CSRF Szenario ist wie:ASP Anti Request Forgery, warum würde der Hacker nicht zuerst einen bekommen?

  1. Erstellen einer Website (wir nennen es HackerSite), die Beiträge zu der Ziel-Website BankingSite
  2. Nutzung Social Engineering (oder XSS in der Werbung etc.), so dass ein Benutzer Besuch Website HackerSite
  3. Ein Skript auf HackerSite zum BankingSite Post wird den Benutzer Cookies/Credentials damit unter seinen/ihren Namen

Aufgrund unserer ARF Token Posting mit, weiß der BankingSite die POST kommt von Standort zu ignorieren H ackerSite. Weil es das richtige AFR-Token fehlt. Kann mir jemand sagen, warum der Hacker das Token nicht einfach durch eine GET-Anfrage auf der BankingSite bekommen konnte? Wie folgt aus:

  1. Erstellen einer Website (wir nennen es HackerSite), die Beiträge zu der Ziel-Website BankingSite
  2. Nutzung Social Engineering (oder XSS in der Werbung etc.), so dass ein Benutzer Besuch Website HackerSite
  3. ein Skript auf HackerSite wird eine GET-Anfrage tun und schnappt sich die ARF-Token aus dem HTML-Code in der Antwort wird diese Anforderung auch die ARF-Token in das Cookie des Benutzers eingestellt
  4. ein zweites Skript auf HackerSite zum BankingSite wird Post Verwendung die packte ARF Token + die Benutzer Cookies/Anmeldeinformationen so Posting unter seinen/ihren Namen

Weiß jemand, was ich hier fehlt, und wie ARF gegen einen solchen Angriff gesichert ist?

+3

Ich denke, dass dieser Link gut erklären das Problem und die Lösung http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks auf 'Fälschungssicherheitstoken funktionieren, weil die böswillige Seite die Token des Benutzers aufgrund derselben Richtlinien nicht lesen kann. ' – Aristos

+0

AFAIK gleichen Ursprungs schützt den Cookie davor, von Javascript gelesen/manipuliert zu werden + schützt gegen IFrames. In meinem Beispiel habe ich die Annahme gemacht, dass ein Hacker leicht Cross-Site-Ajax-Anfragen machen kann (zum Beispiel mit JSONP). Ich denke, dass ich da falsch liegen könnte, was diese Angriffsmethode ungültig macht. Kann jemand überprüfen, dass Sie möglicherweise keine Ajax-Anfragen über die Site stellen können (ohne dass der Browser des Benutzers kompromittiert wird). – Rob

+0

Bitte zeigen Sie uns, wie ein Skript auf HackerSite.com HTML von BankingSite.com im Browser eines Benutzers erhalten kann –

Antwort

1

Angreifer kennt keine Cookies des Opfers. Token generiert basierend darauf. Wenn Ihre Site über weitere XSS-Lücken verfügt, kann diese Methode nicht zur CSRF-Schwachstelle beitragen.

Wenn Sie AJAX Referer Header senden, wäre HackerSite, nicht BankSite. Sie haben also keinen Zugriff auf den geschlossenen Teil der Site (Zugriff auf den CSRF-Token ist nicht möglich). Es ist Http-Only, also können Sie es nicht einfach mit Javascript aufnehmen. Ihr Plan schlägt teilweise fehl, wenn Sie eine Anfrage an die Opferstelle senden möchten.

+0

Wenn ich CSRF richtig verstehe, dann muss der Hacker nicht zu Cookies des Opfers wissen, richtig? Durch eine GET-Anfrage wird das ARF-Token in die Benutzer-Cookies gesetzt, und wenn die POST-Anfrage an die Bankingsite gestellt wird, werden die Cookies des Nutzers verwendet (also der richtige ARF-Token-Cookie gesendet). – Rob

+0

Auth-Cookie ist HttpOnly.Es kann nicht an Javascript vorbeikommen; – devheart

+1

Bei einer Anfrage (normal oder über AJAX) werden alle Cookies automatisch übergeben, HttpOnly oder nicht. – Rob