ASP.NET MVC – CSRF-Angriff

Es gibt eine Art von Angriff, für die wir anfällig sind und die wir oft übersehen Cross Site Request Forgery oder CSRF, ist dies dafür verantwortlich, dass unsere Anwendung dazu verleitet wird, Daten zu empfangen, die nicht von der Domain stammen, in der sie gehostet wird.
Diese Art von Angriff ist ziemlich schädlich, da sie dazu führt, dass ein Benutzer, der getäuscht wurde, seine Authentifizierung verwendet, um Daten in unsere Datenbank einzugeben .
Wie wir erklärt haben, bringt dieser Angriff unsere Anwendung dazu, Daten zu erhalten, die nicht von ihr selbst stammen, dafür nutzt sie die Art und Weise aus, in der sie die Protokolle funktionieren wie HTTP und seine verschiedenen Methoden, dadurch kann ein Angreifer Erstellen Sie ein Formular und verweisen Sie auf unseren Controller.
Um diesen Angriff zu veranschaulichen, betrachten wir den folgenden Controller, der für diese Art von Angriff anfällig ist:

Hier sehen wir, wie wir die Daten direkt aus unserem Formular beziehen und das ist nicht schlecht, das einzige Problem ist, dass wir unserer Anwendung nicht mitteilen, dass sie ihre Herkunft überprüfen muss, damit kann ein Angreifer ein Skript wie das folgende generieren:

VERGRÖSSERN

Hier ist klar, was passiert, wenn diese Seite geladen wird, wird das Formular gesendet, das auf einen bestimmten Datensatz in der Datenbank verweist, dieses Formular zeigt auf einen gültigen Controller. Wenn also ein authentifizierter Benutzer auf diese Seite geleitet wird, befinden wir uns wahrscheinlich in einem ein bisschen binden.
So fatal er auch sein mag, dieser Angriff ist vermeidbar, dafür müssen wir nur einige Validierungen durchführen, die garantieren, dass die empfangenen Daten von unserer Anwendung stammen, dafür können wir einige dieser Techniken verwenden:
Domain-ReferenzDies besteht darin, zu überprüfen, von welcher Domäne die Anfrage stammt. Damit garantieren wir, dass es sich nur um die Domäne handelt, in der unsere Anwendung gehostet wird. Das einzige Problem oder der einzige Nachteil ist, dass wir bei einer Migration unserer Domänenanwendung die Validierung für den Fall möglicherweise neu erstellen müssen haben wir nicht dynamisch gemacht. Es ist auch möglich, einen falschen Verweis zu erstellen, indem Anwendungsschwachstellen ausgenutzt werden, wie z Adobe Flash.
Generiertes TokenMit dieser Option machen wir das in unserem Formular a Zeichen Dies ist für jeden Benutzer einzigartig, sodass unsere Anwendung beim Empfang der Formulare überprüft, ob das Token gleich ist, sodass die Daten akzeptiert werden können oder nicht. Dies ist die am weitesten verbreitete Option, da sie sehr einfach zu implementieren ist und kaum oder keine Nachteile hat.
Im Fall des generierten Tokens ASP.NET MVC enthält einige Methoden, die uns helfen können, die wichtigste ist @ Html.AntiForgeryToken () die den geheimen Schlüssel generiert, mit dem unsere Anwendung die Formulare validieren kann.
Wir sehen also, dass es mehr Bereiche gibt, als wir denken und die wir in unseren Bewerbungen berücksichtigen müssen, also müssen wir uns informieren und uns bewusst sein, wie Angriffe erfolgen, um Wege zu ihrer Vermeidung zu finden.