Utrwalanie sesji SSL i bezpieczne pliki cookie

Question

Mam obecnie własną usługę ochrony aplikacji, która działa w moim przedsiębiorstwie i jest - w większości przypadków - zgodna z potrzebami biznesowymi.

Problem, który obecnie napotykam, polega na tym, że usługa tradycyjnie (naiwnie) polegała na źródłowym IP użytkownika, który pozostaje stały jako zabezpieczenie przed przechwytywaniem sesji - aplikacje internetowe w przedsiębiorstwie nie są bezpośrednio dostępne dla publiczności i w przeszłości całkowicie akceptowalne było dla mnie wymaganie, aby adres użytkownika pozostawał stały przez cały czas trwania sesji.

Niestety tak już nie jest i dlatego jestem zmuszony przełączyć się na rozwiązanie, które nie opiera się na źródłowym IP. Zdecydowanie wolałbym wdrożyć rozwiązanie, które faktycznie spełni pierwotną intencję projektanta (tj. Zapobiegnie przejmowaniu sesji).

Moje dotychczasowe badania okazały się być this, co zasadniczo mówi "salt your hash tokenu uwierzytelniania z kluczem sesyjnym SSL."

Na pierwszy rzut oka wydaje się to idealnym rozwiązaniem, ale pozostaje mi dręczące podejrzenie, że wdrożenie tego systemu w realnym świecie jest niepraktyczne ze względu na możliwość, że klient i serwer może w każdej chwili - skutecznie arbitralnie - zdecyduj się na ponowną negocjację sesji SSL, a zatem zmień klucz.

to jest scenariusz Ja przewidując: Sesja

1. SSL ustalone i uzgodnione klucz.
2. Klient uwierzytelnia się na serwerze na poziomie aplikacji (np. Za pośrednictwem nazwy użytkownika i hasła).
3. Serwer zapisuje bezpieczny plik cookie, który zawiera klucz sesji SSL.
4. Wystąpił element o numerze powodujący ponowną negocjację sesji. Na przykład, myślę, że IE robi to na zegarze z lub bez powodu.
5. Klient przesyła żądanie na serwer zawierający klucz sesyjny stary (ponieważ nie było wiedzy na poziomie aplikacji o renegocjacji, nie było możliwości, aby nowy, zaktualizowany skrót został zapisany do klienta).
6. Serwer odrzuca uwierzytelnienie klienta z powodu mieszania niepowodzenie dopasowania itd

Czy to jest prawdziwy problem lub jest to nieporozumienie z mojej strony ze względu na a (co najmniej) mniej niż doskonałego zrozumienia jak działa SSL?

Answer 1

Tak, ale jest kilka rzeczy, które możesz z tym zrobić. Najprostszym sposobem jest po prostu buforowanie kluczy sesji, których używasz jako soli (na użytkownika), i zaakceptowanie dowolnego z nich. Nawet jeśli sesja zostanie renegocjowana, nadal będziesz mieć ją w pamięci podręcznej. Są szczegóły - polityka wygaśnięcia, itd. - ale nic nie da się ominąć, jeśli nie uruchomisz czegoś, co wymaga zaostrzenia milspec, w takim przypadku nie powinieneś tego robić w ten sposób.

- MarkusQ

Answer 2

Zobacz wszystkie tematy związane z SSL persistence. Jest to dobrze zbadany problem w świecie load-balancer.

Krótka odpowiedź brzmi: nie można polegać na SSLID - większość przeglądarek renegocjuje, a nadal trzeba użyć źródłowego adresu IP.Jeśli adres IP prawdopodobnie zmieni się w trakcie sesji, możesz wymusić ponowne uwierzytelnianie miękkie lub użyć identyfikatora SSLID jako pomostu między dwiema zmianami IP (i na odwrót, tzn. Przyjąć, że jest to tylko adres IP i adres IP i identyfikator SSLID zmiany w tym samym czasie, co widać przez serwer.)

2014 UPDATE

Wystarczy wymusić użycie https i upewnij się, że nie są narażone na session fixation lub CRIME. Nie próbuj solić swojego tokena uwierzytelnienia żadnymi informacjami po stronie klienta, ponieważ jeśli atakujący był w stanie uzyskać token (pod warunkiem, że token nie był prosty do odgadnięcia), to wszelkie inne środki zostały użyte do jego uzyskania (np. cross-site scripting lub pełne kompromisy systemu klienckiego) pozwoli również atakującemu łatwo uzyskać wszelkie informacje po stronie klienta, które mogły trafić do tokena (i jeśli to konieczne, zreplikować je w systemie dodatkowym).

Jeśli klient może łączyć się tylko z kilkoma systemami, może być generate an RSA keypair in the browser dla każdego nowego systemu klienckiego, z którym klient łączy się (gdzie część publiczna jest przekazywana do serwera, a część prywatna pozostaje w tym, co jest mam nadzieję, że bezpieczne przechowywanie klienta) i przekierowanie do hosta wirtualnego, który używa two-way (peer/client certificate) verification zamiast uwierzytelniania opartego na haśle.

Answer 3

Zastanawiam się, dlaczego nie byłoby po prostu wystarczy po prostu

1. wymagać SSL w transporcie
2. wejścia kodowaniu (html/url/atrybutu), aby zapobiec cross-site scripting
3. wymagają jedynie Testy POST dla wszystkich żądań zmieniających informacje i
4. zapobiegają CSRF najlepiej jak potrafisz (w zależności od tego, co obsługuje twoja platforma).
5. Określ cookies do HttpOnly