Während der Arbeit mit ASP.Net Forms Authentication bin ich auf das .ASPXAUTH-Cookie gestoßen. Ich habe ein paar Fragen:
- Was ist der Zweck dieses Cookies?
- Wo befindet sich dieser Cookie?
Was ist ein ASPXAUTH-Cookie?
Antworten:
Das ASPXAUTH-Cookie wird verwendet, um festzustellen, ob ein Benutzer authentifiziert ist.
Was den Speicherort des Cookies betrifft, hängt dies von Ihrem Browser ab. Wenn Sie Firefox verwenden, können Sie das Cookie anzeigen, indem Sie auf Extras -> Optionen -> Datenschutz klicken. Scrollen Sie dann nach unten zur Domäne und erweitern Sie sie, um das Cookie und seinen Wert anzuzeigen. Der Wert wird mit dem Maschinenschlüssel (in der Datei machine.config oder web.config des Servers) verschlüsselt, sodass Sie beim Betrachten des Cookies auf dem Client keine Informationen erhalten. Sie können den Wert auf der Serverseite entschlüsseln / anzeigen, indem Sie:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
Wo authTickethat diese Felder:
Die Anweisung "ASPXAUTH wird grundsätzlich zur Aufrechterhaltung des ASP.NET-Sitzungsstatus verwendet" ist falsch. ASP.NET gibt ein völlig anderes Cookie mit dem Namen ASP.NET_SessionId aus, um den Sitzungsstatus zu verfolgen.
2
Unter Firefox v8.0 sind die Cookies wie folgt zu finden: Tools -> Seiteninfo -> Sicherheit -> Cookies
—
Anthony
Auf derselben Registerkarte "Sicherheit" befindet sich die Schaltfläche "Gespeicherte Kennwörter anzeigen". Zu meiner Überraschung konnte ich alle Kennwörter als einfachen Text für verschiedene Websites anzeigen, die ich mit Firefox durchsucht habe. Obwohl der Browser es in einem verschlüsselten Format auf der Festplatte speichern muss und es nur als Referenz durch Dekodieren anzeigt, ist diese Option wirklich eine Sicherheitsbedrohung, so viel ich denken kann. Wenn ein Hacker denselben Algorithmus verwenden und diese Cookies mit Javascript lesen kann, obwohl das Durchsickern dieses Algorithmus eine entfernte Möglichkeit ist, da es sich möglicherweise auch um einen Schlüssel handelt, der nur dem Browsercode bekannt ist.
—
RBT
Um den Namen des Schlüssels abzurufen, der zum Speichern der Sitzungs-ID von asp.net in der Cookie-Sammlung von http request verwendet wird, geben Sie hier den C # -Code ein: var aspNetSessionState = new System.Web.Configuration.SessionStateSection (); var aspNetSessionCookieName = aspNetSessionState.CookieName;
—
RBT
In
—
Kiquenet
Application_PostAuthenticateRequestder Request.IsAuthenticated ist true, aber .ASPXAUTH kein Wert in meinen HttpContext.Current.Request.Cookies. Ich benutze sessionState.
Ich habe ein MVC-Projekt erstellt und ausgeführt. Registrieren Sie sich und melden Sie sich an. Und überprüfen Sie die Cookies im Chrome Dev Tool, es gab ein Aspnet.ApplicationCookie. Und dann eine Zeile in der Anmeldeaktion hinzugefügt: FormsAuthentication.SetAuthCookie (model.Email, true); und wieder anmelden und die Cookies im Chrome Dev Tool inspizieren, diesmal war es offensichtlich ASPXAuth. Was ist der Unterschied zwischen beiden?
Tatsächlich sagt Ihnen das .ASPXAUTH-Cookie nicht genau, wann der Benutzer wirklich authentifiziert ist. Wenn sich der Benutzer von der App abmeldet, wird das .ASPXAUTH-Cookie aus dem Browser entfernt. Wenn Sie jedoch innerhalb kurzer Zeit (mit Zeitüberschreitung des Formularauthentifizierungs-Cookies) zur Site zurückkehren und die neuen ASP.NET_SessionId-Cookies wie folgt bearbeiten:
- Ändern Sie das Feld "Name" von "ASP.NET_SessionId" in ".ASPXAUTH".
- Ändern Sie "Wert" von 24 Zeichen Sitzungs-ID in alte 448 Zeichen Authentifizierungszeichenfolge
Nach der Aktualisierung können Sie die Identität des authentifizierten Benutzers annehmen, ohne sich erneut technisch zu authentifizieren. .
Ein guter Blog- Beitrag erklärt das Problem ausführlicher. Eine mögliche Lösung besteht darin, die .ASPXAUTH mit der ASP-Sitzung zu koppeln.
Wenn die Interaktionen eines Benutzers mit der HTML-Anmelde-URL es dem TSWPP-Server ermöglicht haben, die Identität des Benutzers festzustellen, MUSS der Remote-Server ein Cookie generieren, das den Benutzer identifiziert und die Authentifizierung beim Server ermöglicht. Der Inhalt des Cookies sollte signiert und verschlüsselt sein. Die spezifische Implementierung dieses Cookies einschließlich der Signatur- und Verschlüsselungsalgorithmen hängt von der Implementierung des TSWPP-Servers ab, da nur der Server den Inhalt des Cookies analysieren muss. Wenn der Server das Cookie implementiert, MUSS das Cookie in einer HTTP-Nutzlast mit dem Inhaltstyp "application / x-msts-webfeed-login" zurückgegeben werden.