Czy szyfrowanie identyfikatora sesji (lub innej wartości uwierzytelnienia) w pliku cookie jest w ogóle użyteczne?

Question

W tworzeniu stron internetowych, gdy włączony jest stan sesji, identyfikator sesji jest przechowywany w pliku cookie (w trybie cookieless zamiast tego używany będzie ciąg zapytania). W asp.net, identyfikator sesji jest szyfrowany automatycznie. W Internecie jest wiele tematów dotyczących sposobu szyfrowania plików cookie, w tym identyfikatora sesji. Rozumiem, dlaczego chcesz szyfrować prywatne informacje, takie jak DOB, ale żadne prywatne informacje nie powinny być przechowywane w ciasteczkach na pierwszym miejscu. Więc dla innych wartości cookie, takich jak identyfikator sesji, jakie jest szyfrowanie celu? Czy to w ogóle zwiększa bezpieczeństwo? bez względu na sposób zabezpieczenia, zostanie odesłany do serwera w celu odszyfrowania.

Bądź być bardziej szczegółowe,

Dla celów uwierzytelniania

1. wyłączyć sesji, i nie chcą zajmować się w czasie sesji na zewnątrz dłużej
2. sklepu jakaś wartość w id ciasteczko, po stronie serwera, sprawdź, czy wartość id istnieje i pasuje, jeśli jest, uwierzytelnia użytkownika.
3. pozwól, aby wartość cookie wygasała po zakończeniu sesji przeglądarki, w ten sposób.

vs

Asp.net mechanizm uwierzytelniania forma (opiera się na sesji lub identyfikator sesji, myślę)

robi ostatnie jedna oferta lepsze bezpieczeństwo?

Answer 1

Ataki na sesje takie jak przejęcie sesji mają na celu uzyskanie prawidłowego identyfikatora sesji. Jeśli teraz zaszyfrujesz identyfikator sesji, atakujący po prostu będą dążyć do zaszyfrowanego identyfikatora sesji i nie będziesz miał żadnej przewagi. Szyfrowanie identyfikatora sesji jest więc bezużyteczne. Pamiętaj, że identyfikator sesji jest po prostu losową wartością używaną do identyfikacji sesji. Atakujący nie muszą wiedzieć, czy ta losowa wartość ma określone znaczenie; oni po prostu muszą znać tę losową wartość.

Jeśli chcesz zabezpieczyć swoją sesję, należy użyć protokołu HTTPS, aby zaszyfrować całą komunikację HTTP przez SSL i ustawić ciasteczka tylko z flagami

• bezpieczne tylko pozwalają cookie należy wysłać za pośrednictwem protokołu HTTPS i
• HttpOnly aby zabronić lokalnego dostępu przez JavaScript.

Answer 2

Myślę, że "należy zawsze zaszyfrować swoje dane" odnosi się do korzystania z SSL w swoich połączeniach za pomocą prawidłowo podpisanego certyfikatu. Spowoduje to zaszyfrowanie całej komunikacji między klientem a serwerem.

Nie widzę żadnego innego zastosowania do dodatkowego szyfrowania identyfikatora sesji (który jest już bardzo losowo generowanym identyfikatorem).

Answer 3

Szyfrowanie losowych rzeczy nie doprowadzi Cię do ...

Answer 4

Jest to udokumentowane w OWASP site

Via web.config w elemencie system.web/httpCookies

<httpCookies httpOnlyCookies="true" …> 

lub programowo

C# Code: 
HttpCookie myCookie = new HttpCookie("myCookie"); 
myCookie.HttpOnly = true; 
Response.AppendCookie(myCookie); 

Answer 5

dane przesyłane przez protokół SSL (https) jest w pełni szyfrowane, nagłówki włączone (stąd pliki cookie), tylko host, do którego wysyłasz żądanie, nie jest zaszyfrowany. Oznacza to również, że żądanie GET jest zaszyfrowane (pozostała część adresu URL). Chociaż osoba atakująca może zmusić klienta do udzielenia odpowiedzi za pośrednictwem protokołu HTTP, dlatego zaleca się używanie w ciasteczku flagi "Bezpieczne", co wymusza użycie protokołu HTTPS do wysyłania plików cookie.

Atrybut Bezpieczne nie ma powiązanych wartości. Zamiast tego obecność nazw atrybutów wskazuje, że określono zachowanie bezpieczne. Atrybut Secure ma na celu ograniczenie komunikacji z plikami cookie do szyfrowanej transmisji, kierując przeglądarki, aby używały plików cookie wyłącznie za pośrednictwem bezpiecznych/szyfrowanych połączeń. Oczywiście, serwery internetowe powinny ustawiać bezpieczne pliki cookie za pośrednictwem bezpiecznych/szyfrowanych połączeń, aby informacje dotyczące plików cookie nie były przesyłane w sposób, który pozwala na podsłuchiwanie przy pierwszym wysłaniu do przeglądarki internetowej.