co to jest plik cookie ASPXAUTH?

80

Podczas pracy z uwierzytelnianiem formularzy ASP.Net natrafiłem na plik cookie .ASPXAUTH. Mam kilka pytań:

  • Jaki jest cel tego pliku cookie?
  • Jaka jest lokalizacja tego pliku cookie?
asp.net cookies forms-authentication balaweblog
źródło

Odpowiedzi:

85

Plik cookie ASPXAUTH służy do określenia, czy użytkownik jest uwierzytelniony.

Jeśli chodzi o lokalizację pliku cookie, zależy to od Twojej przeglądarki. Jeśli używasz przeglądarki Firefox, możesz wyświetlić plik cookie, klikając Narzędzia -> Opcje -> Prywatność. Następnie przewiń w dół do domeny i rozwiń ją, aby zobaczyć plik cookie i jego wartość. Wartość jest szyfrowana przy użyciu klucza maszynowego (znajdującego się w pliku machine.config lub web.config serwera), więc sprawdzenie pliku cookie na kliencie nie dostarczy Ci żadnych informacji. Możesz odszyfrować / wyświetlić wartość po stronie serwera za pomocą:

HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);

gdzie authTicketma te pola:

wprowadź opis obrazu tutaj

Instrukcja „ASPXAUTH jest zasadniczo używana do obsługi stanu sesji ASP.NET” jest niepoprawna. ASP.NET wystawia zupełnie inny plik cookie o nazwie ASP.NET_SessionId w celu śledzenia stanu sesji.

Todd
źródło
2
W przeglądarce Firefox w wersji 8.0 pliki cookie można znaleźć w następujący sposób: Narzędzia -> Informacje o stronie -> Bezpieczeństwo -> Wyświetl pliki cookie
Anthony
W tej samej zakładce bezpieczeństwa znajduje się przycisk „Wyświetl zapisane hasła” i ku mojemu zdziwieniu mogłem zobaczyć wszystkie hasła jako zwykły tekst do różnych stron internetowych, które przeglądałem przy użyciu programu Firefox. Chociaż przeglądarka musi przechowywać go w zakodowanym formacie na dysku i pokazuje go tylko w celach informacyjnych, dekodując go, ale ta opcja jest naprawdę zagrożeniem dla bezpieczeństwa, o ile myślę. Jeśli jakikolwiek haker może zastosować ten sam algorytm i odczytać te pliki cookie za pomocą javascript, chociaż wyciek tego algorytmu jest odległą możliwością, ponieważ może obejmować również klucz, który jest znany tylko kodowi przeglądarki.
RBT
Aby uzyskać nazwę klucza używanego do przechowywania identyfikatora sesji asp.net w kolekcji plików cookie żądania http, oto kod C #: var aspNetSessionState = new System.Web.Configuration.SessionStateSection (); var aspNetSessionCookieName = aspNetSessionState.CookieName;
RBT
W Application_PostAuthenticateRequesttym Request.IsAuthenticated jest prawdą, ale .ASPXAUTH nie wartość w moim HttpContext.Current.Request.Cookies. Używam sessionState.
Kiquenet
1
Stworzyłem projekt MVC, uruchom go. Zarejestruj konto, a następnie zaloguj się. I sprawdź pliki cookie w narzędziu Chrome dla deweloperów, czy jest plik Aspnet.ApplicationCookie. Następnie dodano jedną linię w akcji logowania: FormsAuthentication.SetAuthCookie (model.Email, true); i ponownie zaloguj się i przejrzyj pliki cookie w narzędziu chrome dla deweloperów, tym razem oczywiście był to ASPXAuth. Więc jaka jest różnica w obu?
10

W rzeczywistości plik cookie .ASPXAUTH nie informuje dokładnie, kiedy użytkownik jest naprawdę uwierzytelniony. Gdy użytkownik wylogowuje się z aplikacji, plik cookie .ASPXAUTH jest usuwany z przeglądarki. Jeśli jednak wrócisz do witryny w krótkim czasie (z przekroczeniem limitu czasu pliku cookie uwierzytelniania formularza) i zmodyfikujesz nowe pliki cookie ASP.NET_SessionId, wprowadzając następujące elementy:

  • zmień pole „name” z „ASP.NET_SessionId” na „.ASPXAUTH”
  • zmień „wartość” z 24-znakowego identyfikatora sesji na stary 448-znakowy ciąg uwierzytelniania

Po odświeżeniu będziesz mógł przyjąć tożsamość uwierzytelnionego użytkownika bez ponownego technicznego uwierzytelniania. (ponownie zakładając, że zrobisz to w określonym limicie czasu przechowywanym w zaszyfrowanym ciągu autoryzacji .ASPXAUTH)

Dobry wpis na blogu wyjaśnia problem bardziej szczegółowo. Możliwym rozwiązaniem jest powiązanie .ASPXAUTH z sesją ASP.

Robert
źródło
0

Jeśli interakcje użytkownika z adresem URL logowania w formacie HTML pozwoliły serwerowi TSWPPserver na ustalenie tożsamości użytkownika, serwer zdalny POWINIEN wygenerować plik cookie identyfikujący użytkownika i umożliwiający uwierzytelnianie na serwerze. Zawartość pliku cookie POWINNA być podpisana i zaszyfrowana. Konkretna implementacja tego pliku cookie, w tym algorytmy podpisywania i szyfrowania, zależy od implementacji serwera TSWPP, ponieważ tylko serwer jest zobowiązany do przeanalizowania zawartości pliku cookie. Jeśli serwer implementuje plik cookie, MUSI on zostać zwrócony w ładunku HTTP z typem zawartości „application / x-msts-webfeed-login”.

http://msdn.microsoft.com/en-us/library/ee920427.aspx

Cruiser KID
źródło