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?
co to jest plik cookie ASPXAUTH?
Odpowiedzi:
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:
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.
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
—
Kiquenet
Application_PostAuthenticateRequesttym Request.IsAuthenticated jest prawdą, ale .ASPXAUTH nie wartość w moim HttpContext.Current.Request.Cookies. Używam sessionState.
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?
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.
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”.