Jak to było, everything old is new again czy jakoś tak? Przy czym nie chodzi tutaj o modę, a o pewne umiejętności. Temat jest nawet szerszy, jeśli ktoś siedzi w branży security wystarczająco długo może zauważyć, że niektóre klasy podatności "odżywają" po części dlatego, że zmienia się technologia, a po części dlatego, że następuje rotacja ludzi. Starsi, którzy już nauczyli się już na swoich błędach, idą dalej. Młodsi - muszą się dopiero nauczyć.
To samo dotyczy również testowania. Coś się intensywnie testuje, bo każdy wie, że "tam żyją smoki". Z czasem smoki idą gdzie indziej, a dany obszar jest w miarę sensowny. Czas mija, ktoś zagląda w to samo miejsce i... smoki wróciły.
Dawno, dawno temu zarządzanie sesją często było słabe. W znacznym stopniu dlatego, że z braku gotowych rozwiązań każdy implementował je po swojemu i kończyło się to różnie. Z czasem sytuacja stawała się coraz lepsza i coraz ciężej było znaleźć coś ciekawego, więc i ilość czasu poświęcana na ten temat malała i malała. Z czasem zostało kilka podstawowych testów, plus sprawdzenie, czy wykorzystywane są standardowe rozwiązania.
A potem stało się coś. To coś, to ewolucja mechanizmów uwierzytelnienia w aplikacji i upowszechnienie się rozwiązań SSO. Jednym z częstych schematów implementacji jest użycie "filtra", który sprawdza status uwierzytelnienia (często przez dedykowane cookie), przekierowuje nieuwierzytelnionych użytkowników na stronę logowania, a po powrocie po uwierzytelnieniu - tworzy sesję aplikacyjną. Z reguły z oddzielnym identyfikatorem sesji (ponownie - cookie). No ale w końcu to tylko dodatkowe cookie, więc jeśli już, to będzie bezpieczniej, prawda?
No właśnie nie. To dodatkowe cookie jest na pierwszej linii, więc ciężar typowych testów odnośnie sesji został przeniesiony właśnie na nie. Jest złożone? Super. Ma flagi (httpOnly, Secure, odpowiednie SameSite)? Super. Nothing to see here. A co z tym drugim ciasteczkiem? Czy ono też jest chronione? A kto by się przejmował, przecież to pierwsze jest...
Tutaj właśnie mamy błąd. Trzeba sobie uświadomić, że integracja z SSO jest często dodana. Sama aplikacja natywnie nie rozumie tej warstwy, dla aplikacji sesja jako taka cały czas jest utrzymywana tym "standardowym" identyfikatorem sesji, więc jeśli ktoś będzie w stanie przejąć, powiedzmy, JSESSIONID - dla aplikacji będzie to wystarczające by się pod kogoś podszyć.
I tutaj pojawia się pytanie - ale co z tym "pierwszym i ważniejszym" cookie, nazwijmy je AUTHCOOKIE? A nic. Sprawdzałeś, czy AUTHCOOKIE i JSESSIONID muszą być "sparowane"? Może możesz użyć swojego AUTHCOOKIE, ale cudzego JSESSIONID? Nie sprawdzałeś? A szkoda. Bo często nie są, zwłaszcza gdy integracja z SSO jest "sztukowana".
...i to jest właśnie ten lost art of (...)
