plik cookie sesji jest wystarczająco bezpieczny, aby przechowywać identyfikator użytkownika?

Question

Używam cookie sesji (nie jest to stały), aby zapisać identyfikator użytkownika, aby dowiedzieć się, czy użytkownik jest zalogowany.

w zasadzie użytkownik loguje się, sprawdzamy poświadczenia, a następnie ustawiamy plik cookie sesji userID = 37 (tylko dla tego konkretnego użytkownika, inny użytkownik będzie miał 73 lub 69, etc ...)

Session.Add("UserID", 37); 

moje pytanie brzmi, czy jest możliwe dla użytkownika zalogowanego w jakiś sposób zmienić tę cookie sesji od 37 do 73 i w ten sposób oszukać serwer w przekonaniu, że faktycznie jest użytkownikiem 73? Jeśli TAK, to co robię źle, jak sobie z tym poradzić? wydaje się szalone, aby umieścić identyfikator użytkownika sesji i hash hasła i sprawdzić je KAŻDYM CZASEM?

używamy tej wartości identyfikatora użytkownika również w zapytaniach później, aby je ograniczyć.

Przepraszam, jeśli to nie jest dokładne pytanie kodu, ale jest bardzo istotne dla mojego kodu.

Answer 1

Plik cookie sesji zawiera tylko identyfikator sesji. Służy do identyfikacji użytkownika. Nie zawiera nic więcej. Rzeczywiste informacje dotyczące tej sesji są przechowywane na serwerze. To jest bezpieczne. Użytkownik nigdy nie może zmienić wartości zapisanej na serwerze. Użytkownik nie może zmienić swojego identyfikatora, jeśli zapisałeś go w sesji.

Podczas pracy z identyfikatorami użytkowników można rozważyć użycie numeru forms authentication do śledzenia uwierzytelnionych użytkowników zamiast ponownego wynajdywania kół z sesją.

Answer 2

To nie jest ciasteczko i jest całkowicie bezpieczne, ponieważ nie może zostać zmienione przez użytkownika. Jedyną rzeczą przechowywaną po stronie serwera w pliku cookie jest identyfikator sesji.

Answer 3

Stan sesji ASP.NET zapewnia ważną przewagę w zakresie bezpieczeństwa nad technikami zarządzania stanem klienta, ponieważ stan faktyczny jest przechowywany po stronie serwera i nie jest widoczny na kliencie ani w innych jednostkach sieciowych wzdłuż ścieżki żądania HTTP. Istnieje jednak kilka ważnych aspektów działania stanu sesji, które należy rozważyć w celu utrzymania bezpieczeństwa aplikacji. Najlepsze praktyki w zakresie bezpieczeństwa można podzielić na trzy główne kategorie: zapobieganie fałszowaniu i iniekcyjnemu identyfikatorowi sesji, zabezpieczenie magazynu stanu w zapleczu oraz zapewnienie bezpieczeństwa wdrażania stanu sesji w dedykowanych lub współużytkowanych środowiskach.

Czytaj: Securing Session State

Answer 4

Jak zauważyli inne odpowiedzi, wartość rzeczywista (37 w przykładzie) jest przechowywana na serwerze, a nie klient, ale to nie znaczy, że jesteś odporny na potencjalne ataki. Mechanizm ten jest nadal podatny na ataki typu cross-site scripting. Zasadniczo, to, co jest przechowywane w pliku cookie klienta, to jakiś długi długi identyfikator. Jeśli ktoś inny niż rzeczywisty użytkownik otrzyma ten identyfikator, może umieścić go w pliku cookie i zasadniczo udawać, że jest tym użytkownikiem. Możesz samodzielnie badać skrypty krzyżowe (nie jestem ekspertem w tej dziedzinie), aby zobaczyć niektóre z typowych sposobów, w jakie złośliwy użytkownik spróbuje spojrzeć na pliki cookie innych użytkowników i spróbować ustawić je jako własne wraz ze sposobami obrony przed takimi atakami (niektóre z nich na pewno zrobią dla ciebie przeglądarki i ASP).