Wozu dient das fälschungssichere Token-Salz?

Question

In ASP.NET MVC 1.0 gibt es eine neue Funktion zur Behandlung des Sicherheitsproblems Cross Site Request Forgery:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Ich habe festgestellt, dass sich das im HTML-Formular generierte Token jedes Mal ändert, wenn ein neues Formular gerendert wird.

Ich möchte wissen, wie diese Token generiert werden? Und wenn ich eine Software verwende, um diese Website zu scannen, meldet sie ein weiteres Sicherheitsproblem: Session fixed. Und warum? Da sich der Token ständig ändert, wie kann dieses Problem entstehen?

Und es gibt eine weitere Funktion, nämlich "Salz" für die antiForgeryToken aber ich weiß wirklich, wozu das gut sein soll, auch wenn wir kein "Salz" verwenden, um das Token zu generieren, wird sich das Token ständig ändern, wozu also eine solche Funktion?

Answer 1

Viele Informationen über den AntiForgeryToken hier: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Dies dient der Verhinderung einer Cross-Site Request Forgery (CSRF). Es ist ein ziemliches Standardverhalten, in einem Formular auf "Speichern" zu klicken und eine Aktion auf dem Server durchzuführen, z. B. die Daten eines Benutzers zu speichern. Woher wissen Sie, dass der Benutzer, der das Formular abschickt, derjenige ist, der er vorgibt zu sein? In den meisten Fällen werden Sie ein Cookie oder eine Windows-basierte Authentifizierung verwenden.

Was ist, wenn ein Angreifer Sie auf eine Website lockt, auf der genau dasselbe Formular in einem kleinen versteckten IFRAME angezeigt wird? Ihre Cookies werden unversehrt übermittelt, und der Server sieht keinen Unterschied zwischen der Anfrage und einer legitimen Anfrage. (Wie Google Mail entdeckt hat: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/ )

Das Anti-Fälschungs-Token verhindert diese Form des Angriffs, indem es bei jeder Generierung einer Seite ein zusätzliches Cookie-Token erzeugt. Das Token befindet sich sowohl im Formular als auch im Cookie. Wenn das Formular und das Cookie nicht übereinstimmen, liegt ein CSRF-Angriff vor (da der Angreifer nicht in der Lage wäre, das Anti-Fälschungs-Token mit dem oben beschriebenen Angriff zu lesen).

Und was bewirkt das Salz aus dem obigen Artikel?

Salt ist nur eine beliebige Zeichenfolge. Ein anderer Salt-Wert bedeutet, dass ein anderes fälschungssicheres Token erzeugt wird. Das bedeutet, dass ein Angreifer, selbst wenn es ihm gelingt, irgendwie in den Besitz eines gültigen Tokens zu gelangen, diesen nicht in anderen Teilen der Anwendung wiederverwenden kann, in denen ein anderer Salt-Wert erforderlich ist.

Aktualisierung: Wie wird der Token generiert? Download der source und sehen Sie sich die Klassen AntiForgeryDataSerializer und AntiForgeryData an.

Answer 2

Sie haben ein paar unzusammenhängende Probleme angesprochen:

1. Ich weiß nicht, warum Ihre Sicherheitssoftware "Sitzung beendet" meldet. Versuchen Sie, die Dokumentation zu lesen, die mit dem Bericht geliefert wird
2. Das fälschungssichere Token:

Dies wird (vermutlich) verwendet, um zu überprüfen, ob jede Anfrage gültig ist. Stellen Sie sich also vor, jemand versucht, einen Link zu der Seite ?x=1 Wenn das Token nicht mit übergeben wird, wird die Anfrage abgelehnt. Außerdem wird dadurch (möglicherweise) eine doppelte Buchung desselben Postens verhindert. Wenn Sie zweimal auf "posten" klicken, wird sich das Token wahrscheinlich ändern (bei jeder Anfrage), und dieser Fall wird durch etwas wie "posten" erkannt:

Session["nextToken"] = token;
WriteToken(token);

...

if( !Request["nextToken"] == Session["nextToken"] ){
    ...
}

// note: order in code is slightly different, you must take the token
// before regenerating it, obviously

Ich glaube, der Begriff für diesen Angriff (den er schützt) heißt heutzutage "CSRF" (Cross-Site Request Forgery).