Wenn wir die ASP.NET-Formularauthentifizierung in einem der ASP.NET-Frameworks (ASP.NET MVC, Web Forms usw.) verwenden, behalten wir das Authentifizierungs-Cookie im Client-Browser 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.
Wenn alle vorhanden sind, gehe ich davon aus, dass jemand den Cookie immer noch aus dem Client-Browser herausholen und Anfragen mit diesen Authentifizierungs-Cookie-Werten ausgeben kann. Dies kann vom Server nicht erkannt werden und wir würden geschützte Daten an andere weitergeben.
Ich glaube, ich denke hier daran, das Risiko zu senken, das Passwort des Kunden immer dann zu fragen, wenn er versucht, ernsthafte Maßnahmen zu ergreifen (z. B. Ändern der E-Mail-Adresse, Zugreifen auf Profilinformationen usw.) Löse nichts und kann für den Kunden ziemlich nervig sein.
Haben Sie einen Ansatz, den Sie für diese Art von Problemen aktiv verfolgen? Oder was wäre die beste Möglichkeit, die Authentifizierung im Client-Browser zu erhalten?
Du machst so ziemlich alles richtig mit.
Wenn Sie den Mitgliedschaftsanbieter verwenden, wird das Cookie nur als HTTP markiert (wie Sie bereits sagten), so dass es nicht über ein Client-Skript wie etwa ein böswilliges Stück XSS 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 für .NET-Entwickler Teil 9: Unzureichender Schutz der Transportschicht als zusätzliche Möglichkeit, sicherzustellen, dass Anforderungen weiterhin über einen sicheren Kanal gesendet werden.
Abgesehen davon, dass Sie sich ernsthaft mit dem Mitgliedschaftsanbieter auseinandersetzen müssen, können Sie wirklich nicht viel mehr tun. 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 nachfolgende Anfragen übereinstimmen, aber wir gehen hier sehr detailliert vor.
Letztendlich sollte Sicherheit jedoch auf den Wert der zu schützenden Assets und die Wahrscheinlichkeit schädlicher Aktivitäten zugeschnitten sein. Sie sagen nicht was Sie schützen, aber wenn es sich um ein Finanzsystem handelt, werden Sie größere Anstrengungen unternehmen, als wenn es sich um eine einfache Kommentar-Engine in einem Blog handelt.
Zusammenfassend sieht es so aus, als würden Sie einen großartigen Job machen. Denken Sie nur über die Angemessenheit der Maßnahmen nach, 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, lesen Sie Unser Password Hashing hat keine Kleidung und hör auf damit!
Mit extra auf alles, was Sie getan haben, und im Hinterkopf diese Frage Ich schlage vor, mehr Informationen auf dem Server über den Benutzer zusammen mit dem Authentifizierungs-Cookie zu halten, also wenn jemand stehlen Sie den Cookie und versuchen Sie es zu verwenden, muss auch erfüllen und alle anderen Merkmale des Clients in der Lage sein, es zu verwenden.
Einige der Informationen, die ich aufbewahre und überprüfe, sind dieselben, die mit dem Authentifizierungs-Cookie übereinstimmen.
Ich weiß, dass jemand sagen kann, dass all das von einem Hacker kloniert werden kann - wenn der Hacker den Keks nehmen kann, warum er nicht kommt und der Rest von ihnen. Nun, nichts ist 100% Garantie in den Szenarien und wenn jemand alle Informationen nehmen kann, die es tatsächlich haben kann und das Passwort sein selbst und Login - zumindest machen Sie es ein wenig sicherer.
Sie verwenden bereits HTTPS und verschlüsseln die Cookies, was ziemlich sicher ist.
Wenn Sie sich immer noch Sorgen machen, würde ich vorschlagen, zusätzliche Informationen über die Sitzung des Benutzers auf dem Server zu speichern (IP-Adresse, Benutzeragent usw.) und dies anhand der 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.
Tags und Links asp.net security ssl browser forms-authentication