Wie verhindere ich Wiederholungsangriffe?

Question

Dies hängt damit zusammen noch eine Frage, die ich gestellt habe.Zusammenfassend habe ich einen Sonderfall einer URL, bei der ich mich beim Posten eines Formulars nicht auf Cookies zur Authentifizierung oder zur Aufrechterhaltung der Sitzung des Benutzers verlassen kann, sondern irgendwie wissen muss, wer sie sind, und das brauche ich um zu wissen, dass sie eingeloggt sind!

Ich glaube, ich habe eine Lösung für mein Problem gefunden, aber sie muss konkretisiert werden.Hier ist, was ich denke.Ich erstelle ein verstecktes Formularfeld namens „Benutzername“ und füge darin den verschlüsselten Benutzernamen des Benutzers ein.Wenn dann das Formular POST sendet, obwohl ich keine Cookies vom Browser erhalte, weiß ich, dass sie angemeldet sind, weil ich das ausgeblendete Formularfeld entschlüsseln und den Benutzernamen erhalten kann.

Die größte Sicherheitslücke, die ich sehe, sind Replay-Angriffe.Wie kann ich verhindern, dass jemand an diese verschlüsselte Zeichenfolge gelangt und als dieser Benutzer postet?Ich weiß, dass ich SSL verwenden kann, um den Diebstahl dieser Zeichenfolge zu erschweren, und vielleicht kann ich den Verschlüsselungsschlüssel regelmäßig wechseln, um die Zeitspanne zu begrenzen, für die die Zeichenfolge gültig ist, aber ich würde wirklich gerne eine kugelsichere Lösung finden Lösung.Hat jemand irgendwelche Ideen?Verhindert der ASP.Net ViewState die Wiedergabe?Wenn ja, wie machen sie das?

Bearbeiten:Ich hoffe auf eine Lösung, die keine Speicherung in einer Datenbank erfordert.Der Anwendungsstatus wäre in Ordnung, außer dass er einen IIS-Neustart nicht übersteht und in einem Webfarm- oder Gartenszenario überhaupt nicht funktioniert.Ich akzeptiere Chris‘ Antwort vorerst, weil ich nicht davon überzeugt bin, dass es überhaupt möglich ist, dies ohne eine Datenbank zu sichern.Aber wenn jemand eine Antwort findet, die nicht die Datenbank betrifft, akzeptiere ich sie!

Answer 1

Wenn Sie einen Zeitstempel zusammen mit dem Benutzernamen und dem Passwort eingeben, können Sie das Fenster für Replay-Angriffe auf wenige Sekunden schließen.Ich weiß nicht, ob dies Ihren Anforderungen entspricht, aber es ist zumindest eine Teillösung.

Answer 2

Wenn Sie wirklich keinen Status speichern möchten, ist es meiner Meinung nach das Beste, Wiederholungsangriffe durch die Verwendung von Zeitstempeln und einer kurzen Ablaufzeit einzuschränken.Beispielsweise sendet der Server:

{Ts, U, HMAC({Ts, U}, Ks)}

Dabei ist Ts der Zeitstempel, U der Benutzername und Ks der geheime Schlüssel des Servers.Der Benutzer sendet dies an den Server zurück und der Server validiert es, indem er den HMAC anhand der bereitgestellten Werte neu berechnet.Wenn es gültig ist, wissen Sie, wann es ausgestellt wurde, und können es ignorieren, wenn es älter als beispielsweise 5 Minuten ist.

Eine gute Ressource für diese Art der Entwicklung ist Die Vor- und Nachteile der Clientauthentifizierung im Web

Answer 3

Hier gibt es mehrere gute Antworten, und wenn man sie alle zusammenfasst, liegt letztendlich die Antwort:

1. Blockverschlüsselung (mit AES-256+) und Hash (mit SHA-2+) aller Status-/Nonce-bezogenen Informationen, die an einen Client gesendet werden.Hacker manipulieren ansonsten einfach die Daten, sehen sie sich an, um die Muster zu erkennen und alles andere zu umgehen.Erinnern ...es braucht nur ein geöffnetes Fenster.

2. Generieren Sie eine einmalige, zufällige und eindeutige Nonce pro Anfrage, die mit der POST-Anfrage zurückgesendet wird.Dies bewirkt zwei Dinge:Es stellt sicher, dass die POST-Antwort zu DIESER Anfrage gehört.Es ermöglicht auch die Verfolgung der einmaligen Verwendung eines bestimmten Satzes von get/POST-Paaren (wodurch eine Wiederholung verhindert wird).

3. Verwenden Sie Zeitstempel, um den Nonce-Pool überschaubar zu machen.Speichern Sie den Zeitstempel in einem verschlüsselten Cookie gemäß Nr. 1 oben.Verwerfen Sie alle Anfragen, die älter sind als die maximale Antwortzeit oder Sitzung für die Anwendung (z. B. eine Stunde).

4. Speichern Sie einen „ziemlich eindeutigen“ digitalen Fingerabdruck des Computers, der die Anfrage stellt, mit den verschlüsselten Zeitstempeldaten.Dies verhindert einen weiteren Trick, bei dem der Angreifer die Cookies des Clients stiehlt, um Session-Hijacking durchzuführen.Dadurch wird sichergestellt, dass die Anfrage nicht nur einmal zurückkommt, sondern auch von der Maschine (oder so nah, dass es für den Angreifer praktisch unmöglich ist, sie zu kopieren), an die das Formular gesendet wurde.

Es gibt auf ASPNET- und Java/J2EE-Sicherheitsfiltern basierende Anwendungen, die alle oben genannten Aufgaben ohne Codierung ausführen.Die Verwaltung des Nonce-Pools für große Systeme (z. B. ein Aktienhandelsunternehmen, eine Bank oder eine sichere Website mit hohem Volumen) ist kein triviales Unterfangen, wenn die Leistung von entscheidender Bedeutung ist.Ich würde empfehlen, sich diese Produkte anzusehen, anstatt zu versuchen, dies für jede Webanwendung zu programmieren.

Answer 4

Sie könnten eine Art zufällige Challenge-Zeichenfolge verwenden, die zusammen mit dem Benutzernamen zum Erstellen des Hashs verwendet wird.Wenn Sie den Challenge-String auf dem Server in einer Datenbank speichern, können Sie sicherstellen, dass er nur einmal und nur für einen bestimmten Benutzer verwendet wird.

Answer 5

In einer meiner Apps zum Stoppen von „Replay“-Angriffen habe ich IP-Informationen in mein Sitzungsobjekt eingefügt.Jedes Mal, wenn ich im Code auf das Sitzungsobjekt zugreife, stelle ich sicher, dass ich die Request.UserHostAddress mitgebe, und vergleiche dann, um sicherzustellen, dass die IPs übereinstimmen.Wenn nicht, dann hat offensichtlich jemand anders als die Person diese Anfrage gestellt, also gebe ich null zurück.Es ist nicht die beste Lösung, aber es ist zumindest ein weiteres Hindernis, um Wiederholungsangriffe zu stoppen.

Answer 6

Können Sie zur Wartung Speicher oder eine Datenbank verwenden? beliebig Informationen über den Benutzer oder Anfrage überhaupt?

Wenn ja, dann würde ich auf Anfrage für das Formular ein verstecktes Formularfeld einfügen, dessen Inhalt eine zufällig generierte Zahl ist.Speichern Sie dieses Token im Anwendungskontext oder in einem Speicher (Datenbank, Flatfile usw.), wenn die Anforderung gerendert wird.Überprüfen Sie beim Absenden des Formulars den Anwendungskontext oder die Datenbank, um festzustellen, ob die zufällig generierte Nummer noch gültig ist (wie auch immer Sie sie als gültig definieren – sie kann möglicherweise nach X Minuten ablaufen).Wenn ja, entfernen Sie dieses Token aus der Liste der „erlaubten Token“.

Daher würden alle wiederholten Anforderungen denselben Token enthalten, der auf dem Server nicht mehr als gültig angesehen wird.

Answer 7

Einige Aspekte der Webprogrammierung sind für mich neu, aber ich habe mich neulich darüber informiert.Ich glaube, Sie müssen a verwenden Nonce.

Answer 8

(Bei Replay-Angriffen kann es leicht um IP/MAC-Spoofing gehen, außerdem sind Sie bei dynamischen IPs vor Herausforderungen.)

Es geht hier nicht nur um eine Wiederholung, für sich genommen ist es bedeutungslos.Verwenden Sie einfach SSL und vermeiden Sie manuelles Erstellen.

ASP.Net ViewState ist ein Chaos, vermeiden Sie es.Während PKI schwergewichtig und aufgebläht ist, funktioniert es zumindest, ohne dass Sie eigene Sicherheitspläne erfinden müssen.Wenn ich könnte, würde ich es also verwenden und immer auf gegenseitige Authentifizierung setzen.Die reine Serverauthentifizierung ist völlig nutzlos.

Answer 9

Der ViewState umfasst Sicherheitsfunktionen.Sehen Dieser Artikel über einige der integrierten Sicherheitsfunktionen in ASP.NET.Es führt eine Validierung anhand des Server-MachineKey in der machine.config auf dem Server durch, wodurch sichergestellt wird, dass jedes Postback gültig ist.

Weiter unten im Artikel, sehen Sie auch, dass Sie die verwenden können, wenn Sie Werte in Ihren eigenen ausgeblendeten Feldern speichern möchten LosFormatter Klasse, um den Wert auf die gleiche Weise zu kodieren, die ViewState zur Verschlüsselung verwendet.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Answer 10

Wenn Sie jeden Schlüssel nur einmal akzeptieren (z. B. den Schlüssel zu einer GUID machen und dann prüfen, wann er zurückkommt), würde dies Wiederholungen verhindern.Natürlich, wenn der Angreifer reagiert Erste, dann hast du ein neues Problem...

Answer 11

Ist das WebForms oder MVC?Wenn es sich um MVC handelt, können Sie das AntiForgery-Token verwenden.Dies scheint dem von Ihnen erwähnten Ansatz zu ähneln, außer dass grundsätzlich eine GUID verwendet und ein Cookie mit dem Guid-Wert für diesen Beitrag gesetzt wird.Weitere Informationen hierzu finden Sie im Blog von Steve Sanderson: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Haben Sie außerdem darüber nachgedacht, den Referrer im Postback zu überprüfen?Das ist nicht kugelsicher, aber es kann helfen.

Answer 12

Verwenden Sie https...Es verfügt über einen integrierten Wiedergabeschutz.