Schaffung einer AntiForgeryToken durch Abhängigkeitsinjektion
https://stackoverflow.com/questions/1702324
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich arbeite an der Verbesserung der Sicherheit der Website meines Unternehmens und wollte ein Token erstellen, um Fälschungsversuche zu verhindern, die leicht aufrechterhalten werden könnten, dies ist das, was ich mir ausgedacht habe.
public class AntiForgeryToken
{
private readonly string _referenceToken;
public AntiForgeryToken()
{
_referenceToken = Guid.NewGuid().ToString();
}
public string ReferenceToken
{
get { return _referenceToken; }
}
}
In meiner Basisklasse für meine Meisterseite habe ich ein verstecktes Field mit dem Namen: Named: ReferenceToken
protected virtual void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
InjectToken();
}
ValidateToken();
}
private void InjectToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
ReferenceToken = token.ReferenceToken;
}
private void ValidateToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
if (ReferenceToken.Equals(token.ReferenceToken, SC.InvariantCultureIgnoreCase))
return;
...do stuff for failed token
}
Ich habe Structuremap -Handle, um das Token innerhalb der Sitzung zu speichern, sodass es pro Benutzersitzung bestehen bleibt. Wäre dies all dies eine gültige Implementierung eines Antiforgery -Schemas?
Bearbeiten: Es scheint eine gewisse Verwirrung in meiner Frage zu geben. Ja, ich verstehe Webformen Um die Verwendung eines CSRF -Angriffs zu verhindern (Cross -Standort -Anfrage -Fälschung). Ich verstehe, dass dies die Notwendigkeit einer ordnungsgemäßen Genehmigung der Benutzerrechte beseitigt.
Ich wollte den Link, den @Neal und @Solairaja gepostet haben, ansprechen: Verhindern Sie die CSRF (Querstellen-Anfrage "(CSRF) unter Verwendung von ASP.NET MVCs AntiforgeryToken () -Helfer. Dieser Artikel erklärt mehr von dem, was der CSRF -Angriff ist und wie MVC ihn stoppt, aber ihre Lösung ist nicht für Webformen anwendbar, weshalb ich meine eigenen implementiert habe.
Nachdem ich die Antwort von @Neal gesehen habe, denke ich, dass dies höchstwahrscheinlich die akzeptierte Antwort sein wird, da ich nicht bemerkte, dass ich nur den tatsächlichen Quellcode aus dem MVC -Tool erhalten konnte, das höchstwahrscheinlich die Guid -Erstellung ersetzen wird. Aber ich werde die Frage offen lassen, ob jeder andere einige wertvolle Informationen hinzufügen kann.
Lösung
Chris,
Ihr Ansatz ahmt mehr oder weniger den Anti-Empan-Ansatz in MVC nach, außer dass sie ein von RNGcryptoServiceProvider erzeugter Basis64-Coded-Byte-Array verwenden und das Token sowohl auf der Seite (verstecktes Formfeld) als auch in einem Cookie speichern. Ich würde empfehlen, mehr Logik in die Token -Implementierung zu bewegen (z. B. den größten Teil der Validierungslogik innerhalb des Tokens einkapseln).
Der Code für die MVC -Implementierung ist unter frei zugänglich bei http://aspnet.codeplex.com/sourcecontrol/changeset/view/23011?projectname=aspnet#391757 Wenn möglich, sollten Sie dies wahrscheinlich sowohl überprüfen als auch http://blog.codeville.net/2008/09/01/prevent-cross--Sequest-request-forgery-csrf-using-aspnet-mvcs-antifergerytoken-helper/ für eine Analyse + Ideen.
Andere Tipps
ASP.NET -Webformulare verhindert standardmäßig CSRF -Angriffe, wenn Sie den Ansichtszustand verwenden. Wenn Sie nicht in Ihrer Anwendung effektiv deaktiviert haben, fügen Sie Code hinzu, um ein Problem zu lösen, das Sie nicht haben.
View State verhindert CSRF -Angriffe
.NET CSRF Guard - Owasp
Zunächst sollte ich mir fragen ... was meinst du wirklich mit "Antiforgery"? Was besorgt Sie darüber, gefälscht zu werden? Der Rest von dem, was folgt, sind nur einige allgemeine Informationen, die in den Sinn kommen ...
Eine Sache, die ich ändern würde, ist, Guid.newguid nicht zu verwenden. Es gibt eine Debatte darüber, ob es zufällig ist oder nicht und daher nicht für Sicherheitszwecke geeignet ist. Das heißt, ich denke, es wäre ein sehr harter Angriff, um sich abzuziehen.
Schauen Sie sich RngcryptoServiceProvider für die GetByTes -Methode für etwas an, das besser für die Generierung eines zufälligen Tokens sein sollte. Zusätzlich zu einer besseren Zufälligkeit ist ein weiterer Vorteil dafür, dass Sie es zu jeder gewünschten Größe machen können.
Machst du das über SSL? Zunächst einmal ist SSL eine Verteidigungslinie Nummer eins für den Menschen in den mittleren Angriffen. Es ist vielleicht nicht sicher genug (und andere können darüber diskutieren) für jeden Bedarf, aber wenn Sie sich um solche Dinge kümmern, ist es der Ausgangspunkt, wenn nichts anderes. Wenn nicht, wie stellen Sie sicher, dass Sie eine Antwort von der richtigen Maschine und nicht von einem Mann in der Mitte erhalten, der zuerst antwortet? Ohne SSL oder ein Äquivalent ist Ihr Token genauso leicht gestohlen wie alles andere, was Sie tun.
Eine weitere Sache, die Sie hinzufügen sollten, ist, dass Ihre Token nur für eine Reise gut sind und Sie bei der nächsten Reise einen neuen zurück zum Kunden erstellen. Der Versuch, es wiederzuverwenden, schlägt fehl.
Ich würde nicht Versuchen Sie, SSL durch etwas anderes von Ihrer eigenen Erfindung zu ersetzen, wenn Sie das denken. Wenn Sie sich jedoch um eine Wiederholung kümmern, ist eine Time Token -Generation eine Möglichkeit, sie zu stoppen. Wenn Sie sich Sorgen machen, dass ein Benutzer zweimal die gleichen Formulardaten einreicht, ist dies eine Sache. Ich würde auch Ihr allgemeine Anwendungsdesign in Betracht ziehen, wenn Sie sich darüber Sorgen machen würden. Viele Wiederholungen und ähnliche Szenarien können durch Sounddesign Ihrer Geschäftslogik besiegt werden, z.
Bitte lesen Sie auch die verschiedenen Microsoft -Anleitungen zu ASP.NET und IIS Security (dh Google ASP.NET oder IIS Security Site: Microsoft.com) als Ausgangspunkt. Viele kluge Leute haben bereits viele Probleme für uns gelöst.
Wäre dies all dies eine gültige Umsetzung eines Antiforgery -Programms?
Soweit ich das beurteilen kann, sieht es so aus, als würden Sie eine Leitfaden für eine Seite einfügen und dann nach dem gleichen GUID suchen, wenn die Seite zurückkommt.
Ich weiß nicht, was Ihre Anforderungen sind, daher kann ich nicht sagen, ob das Schema wirklich "gültig" ist. Ich kann jedoch auf ein paar Dinge hinweisen:
- Wenn die Richtlinie nur auf der Seite lebt, was würde dann ein Benutzer daran hindern, die Seite auf einer Maschine zu lesen und das Formular von einem anderen zu übermitteln? Es wäre gut, es mit einem Cookie oder einer Sitzung (in der auch ein Cookie verwendet wird) zu verbinden, wenn Sie es nicht schon nicht haben.
- Wenn die Richtlinie als statische versteckte Seite in die Seite geschrieben ist
<input>Feld, dann konnte das Formular von Bots gelesen und eingereicht werden. Sie können dies umgehen, indem Sie ein Skript auf der Seite verlangen, um das Token zu verarbeiten, bevor Sie es senden. - Verwenden Sie ViewState? In diesem Fall können Sie nur in Betracht ziehen, nur einzustellen
ViewStateUserKeyzu einem wiederholbaren Wert, der pro Kunden eindeutig ist; Es führt eine ähnliche Funktion wie das, was Sie hier beschrieben haben.
Wie Nick sagte, sieht auch für mich auch der Code, den Sie gegeben haben, so aus, als würden Sie eine Leitfaden für eine Seite einfügen und dann nach dem gleichen GUID suchen, wenn die Seite zurückkommt. Das ist auch eine gute Idee, wenn Sie eine Strukturkarte verwenden, die in die Sitzung speichert.
Für diese Antiforgery -Konzepte stehen jedoch einige eingebaute Methoden zur Verfügung.
Bitte beziehen Sie sich zuerst auf den folgenden Link und verstehen Sie
Jetzt,
Überprüfen Sie den folgenden Link für die Detailsbeschreibungen und Methodik des Annäherung.
http://msdn.microsoft.com/en-us/library/system.web.mvc.htmlhelper_methods.aspx
Vielen Dank !!
Das sieht mir so aus, als würde es mit jeder Anfrage einen Kanarienvogel generieren. Was passiert nun, wenn ein Benutzer mehrere Registerkarten öffnet? :)
Das Problem mit Ihrem Ansatz (und der ASP.NET -MVC -Implementierung) besteht darin, dass die Entwickler sie implementieren. Sicherheitsmöglichkeiten wie diese sollten angelangt sein, nicht anmelden. Als ich eine schrieb Possenmodul Am Ende habe ich stattdessen den Lebenszyklus der ASP.NET -Seite verwendet, was keine Änderungen am zugrunde liegenden Code bedeutet, es sei denn, ein Entwickler wollte eine Seite aus den CSRF -Überprüfungen entscheiden. Sie werden feststellen, dass es ein einzelnes Token verwendet, das für die Lebensdauer der Browser -Sitzung dieses Benutzers dauert - es besteht kein tatsächlicher Bedarf, das Token mit jeder Anfrage zu ändern.
Jetzt habe ich das Modul hauptsächlich geschrieben, um einige Konzepte für mein Forther -Buch zu veranschaulichen (Anzeige hier einfügen Grinsen), Sie könnten das natürlich verwenden ViewStateUserKey, Aber auch dies ist eher Opt-In als Opt-out.
Erste Sicherheitsregel: Versuchen Sie nicht, Ihre eigene Sicherheit zu rollen
So wie ich Ihre Beschreibung verstehe, wäre das kein gültiges Anti-Emporation-Schema. Alles, was ein Angreifer umgehen müsste, wäre es, die zu verwenden Quelltext anzeigen Merkmal seines Browsers, um das Token zu finden. Dann konnte er oder sie alles posten, was sie mögen, solange sie sich daran erinnern, dieses Token zu posten, und Ihr Code würde den Unterschied nicht kennen.
Entschuldigung, wenn ich Ihre Beschreibung völlig missverstanden habe ...
Anstatt wie diese Anti -Fälsch -Token zu verwenden, würde ich bestätigen, dass der authentifizierte Benutzer tatsächlich über die erforderlichen Rechte verfügt, um die angeforderten Änderungen vorzunehmen.
EG ist die Webseite, eine "Benutzerseite erstellen". Ich würde überprüfen, ob der authentifizierte Benutzer autorisiert ist, um neue Benutzer zu erstellen. Ist die Seite "Benutzer x Seite bearbeiten", würde ich überprüfen, ob der authentifizierte Benutzer die Autorisierung hat, um Benutzer X zu ändern. Vielleicht, weil er selbst Benutzer X oder ein administrativer Benutzer ist.
Die Verwendung von Richtlinien ist jedoch nicht sehr sicher. GUIDs werden auf der Grundlage eines Algorithmus erstellt, der für Einzigartigkeit und nicht zufällig geschrieben wurde. AFAIK Es gibt drei gültige Algorithmen, namentlich basiert, zeitbasiert und zufällig. Wenn der vom System verwendete Richtalgorithmus (das durch eine zukünftige .NET -Version geändert werden kann) zeitbasiert ist, ist das Erraten gültiger GUIDs nicht sehr schwierig.
