2009-04-23 16 views
6

Zauważyliśmy, że możliwe jest odtworzenie kopii pliku cookie ASP.NET FormsAuthentication na innym komputerze, umożliwiając uwierzytelnienie drugiej maszyny bez konieczności logowania.Czy mogę uczynić moje pliki cookie ASP.NET FormsAuthentication bardziej bezpiecznymi poprzez powiązanie ich z identyfikatorem sesji?

Jednym z sugerowanych rozwiązań było przechowywanie identyfikator sesji w numerze FormsAuthenticationTicket.UserData i sprawdź, czy te dwie wartości są zgodne z Application_AuthenticateRequest().

Używamy:

FormsAuthenticationTicket.IsPersistent = false; 

Czy to podejście obcowania FormsAuthentication ciasteczko z identyfikatorem sesji to dobry pomysł?

+0

Czy to jest coś, co faktycznie wypróbowałeś? Czy faktycznie masz inne logowanie do komputera, używając pliku cookie z innego komputera? Myślałem, że jest szyfrowanie na sesję. –

+0

Kolega wypróbował to. Nie wiem, czy skonfigurowano szyfrowanie. – tjrobinson

Odpowiedz

18

Myślę, że nadmiernie zastanawiasz się nad problemem. Możliwość kopiowania plików cookie jest tylko nieodłącznym problemem plików cookie - każdy może przechwycić dowolny plik cookie i podszyć się pod dowolne dane, konfigurując je na innej maszynie.

"Bezpieczeństwo" pliku cookie uwierzytelniającego wynika z faktu, że nikt nie może (rzekomo) ręcznie spreparować pliku cookie w celu sfałszowania uwierzytelnionego użytkownika. Jednak po utworzeniu pliku cookie można go oczywiście użyć do uwierzytelnienia. Oznacza to, że aby twój "problem" się wydarzył, musisz najpierw mieć prawidłowe logowanie użytkownika. Jeśli ten użytkownik nadużywa systemu, kopiując jego pliki cookie na inne komputery, aby dać wszystkim dostęp, jest to dokładnie to samo, co użytkownik, który po prostu mówi wszystkim jej nazwę użytkownika i hasło, z wyjątkiem znacznie bardziej rozwlekłych. Dlatego problemem nie jest kopiowanie pliku cookie - to sam użytkownik.

Innym atakiem byłoby, gdyby sieć została naruszona, a ktoś może przechwycić ruch, aby złożyć ciasteczko przez sniffer lub cokolwiek innego - ale znowu jest to nieodłączne od samych ciasteczek. Nazywa się to Session Hijacking, a jedynym sposobem zabezpieczenia się przed tym jest użycie SSL dla twojej witryny.

Jeśli naprawdę się o to martwisz, po prostu ustawiłabym twoje uwierzytelnianie i limity czasu sesji na takie same, a następnie w pliku global.asax, po prostu wywołaj FormsAuthentication.Signout() za każdym razem, gdy wygasa sesja użytkownika. To unieważnia uwierzytelnianie za każdym razem, gdy użytkownik wykonuje swoją sesję, zmuszając ich do ponownego zalogowania się później. Oczywiście, może to być bardzo irytujące dla użytkowników ...

Gorąco polecam również This MSDN article. Prawdopodobnie odpowiada na twoje pytania o wiele lepiej niż ja.

+0

Dziękuję za odpowiedź - w rzeczywistości jest to zgodne z tym, o czym myślałem, ale chciałem drugiej opinii, zanim spróbowałem naprawić coś, co nie było problemem. Sugerowana metoda FormsAuthentication.Signout() nie wydaje się mieć zastosowania w moim przypadku, ponieważ ciasteczko uwierzytelniające wygasa na koniec sesji - zmuszając użytkowników do logowania się w każdej nowej sesji. A może coś przeoczyłem? – tjrobinson

+1

Co w przypadku, gdy komputer użytkownika zostaje zainfekowany wirusem, który kradnie jego plik cookie? SSL nie ochroni ich wtedy. Przypuszczam, że jest to tylko zmiana porywania sesji w tym przypadku. – tjrobinson

+1

Dot .: pierwszy komentarz. Nie sądzę, że coś przeoczyłeś. Wczoraj zastanawiałem się nad tym i pomyślałem, że możesz spróbować ustawić niektóre dane użytkownika w bilecie uwierzytelniania, na przykład adres IP lub coś takiego, a jeśli te informacje się zmienią, automatycznie je wylogować. Utrudnia to podszywanie się pod inną maszynę ... ale adres IP również może zostać sfałszowany. Byłoby jednak trochę bezpieczniejsze. Re: drugi komentarz - tak, kolejna odmiana. – womp

Powiązane problemy