ASP.NET-Formularauthentifizierung und dauerhafte Authentifizierung Cookie-Sicherheit

Question

Wenn ASP.NET-Formularauthentifizierung in ASP.NET-Frameworks (ASP.NET MVC, Web Forms usw.) verwendet wird, behalten wir das Authentifizierungscookie im Clientbrowser bei . Als Best Practice setzen wir den Cookie als HttpOnly und Secure. Wir machen auch alle Transaktionen über SSL. Unabhängig von der Art des Mechanismus, mit dem wir den Benutzer authentifizieren (OAuth, ASP.NET-Mitgliedschaftsanbieter usw.), müssen wir die Authentifizierung für eine bessere Benutzererfahrung beibehalten.

Mit all diesen bin ich davon ausgegangen, dass jemand immer noch das Cookie aus dem Client-Browser erhalten und Anfragen mit diesen Auth-Cookie-Werte ausgeben kann. Dies kann vom Server nicht erkannt werden und wir würden geschützte Daten an andere weitergeben.

Denken Sie daran, das Risiko hier zu verringern, ist das Passwort des Kunden jedes Mal zu fragen, wenn er versucht, einige ernsthafte Maßnahmen (wie das Ändern der E-Mail-Adresse, Profilinformationen, etc.) zu ergreifen löst nichts und kann für den Kunden ziemlich nervig sein.

Haben Sie einen Ansatz, den Sie aktiv für diese Art von Problemen verfolgen? Oder was wäre die beste Möglichkeit, um die Authentifizierung im Client-Browser zu erhalten?

Answer 1

Sie tun ziemlich alles, um mit zu sein.

Wenn Sie den Mitgliedschaftsanbieter verwenden, wird der Cookie nur als HTTP markiert (wie Sie bereits sagten), sodass er nicht über Clientskript wie z. B. ein bösartiges XSS-Element zugänglich ist.

Wenn Sie das Cookie als sicher markiert haben, dann nehme ich an, dass Sie das Flag "RequireSSL" für Formulare auth auf true gesetzt haben. Dadurch wird der Cookie nicht in Anfragen an den Server gesendet, die nicht über HTTPS hinausgehen, selbst wenn Sie versehentlich eine HTTP-Anfrage einreichen (über die der Browser den Benutzer trotzdem warnen sollte, wenn der Inhalt eingebettet ist) eine HTTPS-Seite), werden die Cookies nicht gesendet.

Die einzige andere Sache, die Sie tun könnten - und das bietet nicht viel Verteidigung zu dem, was Sie haben, aber es ist eine gute Übung - ist auch HSTS zu verwenden. Ich spreche darüber in OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection als ein zusätzliches Mittel, um sicherzustellen, dass Anfragen weiterhin über einen sicheren Kanal gesendet werden.

Kurz vor einer ernsthaften Re-Engineering der Mitgliedschaft Anbieter gibt es wirklich nicht viel mehr Sie tun können. Sie können die Sitzung an eine IP-Adresse binden und keine Anfragen akzeptieren, wenn sich diese ändert. Dies kann jedoch zu Problemen führen (z. B. IPs, die sich ändern und Sie nicht vor mehreren Personen an derselben Adresse schützen). Sie könnten auch einen Fingerabdruck des Browsers erstellen (d. H. Alles, was in den Anforderungsheadern gesendet wurde) und sicherstellen, dass die nachfolgenden Anfragen übereinstimmen, aber wir kommen hier sehr detailliert ins Detail.

Letztendlich sollte die Sicherheit jedoch auf den Wert der zu schützenden Assets und die Wahrscheinlichkeit schädlicher Aktivitäten abgestimmt sein. Sie sagen nicht was es ist Sie schützen, aber wenn es ein Finanzsystem ist, gehen Sie zu größeren Längen als wenn es eine einfache Kommentar-Engine in einem Blog ist.

Zusammenfassend sieht es so aus, als würden Sie einen großartigen Job machen, denken Sie nur an die Angemessenheit der Maßnahmen, die Sie im Zusammenhang mit dem Wert dessen, was Sie schützen, implementiert haben. Oh - und wenn Sie den SQL-Mitgliedschaftsanbieter für den Speicher für Anmeldeinformationen verwenden, sollten Sie sicherstellen, dass Sie Our password hashing has no clothes lesen und dann aufhören!

Answer 2

Sie verwenden bereits HTTPS und verschlüsseln die Cookies, was ziemlich sicher ist.

Wenn Sie immer noch besorgt sind, würde ich vorschlagen, zusätzliche Informationen über die Sitzung des Benutzers auf dem Server (IP-Adresse, User Agent, usw.) zu speichern und dies mit den während der Sitzung bereitgestellten Informationen zu überprüfen.

Wenn der Benutzer seine E-Mail-Adresse ändert, können Sie einen Widerruf-Link an die ursprüngliche E-Mail-Adresse senden. Wenn diese Änderung nicht autorisiert ist, wird der wahre Besitzer auf die Änderung hingewiesen.

Answer 3

Mit extra auf alles, was Sie getan haben, und im Sinn this question Ich schlage extra vor, mehr Informationen auf dem Server über den Benutzer zusammen mit dem Authentifizierungscookie zu halten, also wenn jemand den Cookie stiehlt und versucht, ihn zu benutzen , muss auch erfüllen und alle übrigen Merkmale des Kunden in der Lage sein, es zu nutzen.

Einige der Informationen, die ich aufbewahre und überprüfe, sind dieselben, die auch mit dem Authentifizierungscookie übereinstimmen.

1. Session-Cookie mit dem Authentifizierungs-Cookie verbunden.
2. Browser-ID mit
3. Ip des Benutzers verbunden mit
4. Javascript verbunden ist, muss

ermöglichen werden, ich weiß, dass einige kann man sagen, dass alle Klon von einem Hacker sein kann - wenn der Hacker kann den Keks warum nicht bekommen und den Rest von ihnen. Nun, nichts ist 100% Garantie in den Szenarien und wenn jemand alle Informationen nehmen kann, die er tatsächlich haben kann und das Passwort sein selbst und Login - zumindest machen Sie es ein wenig sicherer.