JDD2014: Uwierzytelnianie i zarządzanie sesją w Java EE (P. Bucki)

### Overview Podczas konferencji JDD 2014 Piotr Bucki (ówczesny CTO w j-labs) przedstawił zagadnienia związane z uwierzytelnianiem i zarządzaniem sesją w aplikacjach webowych, ze szczególnym uwzględnieniem środowiska Java Enterprise Edition (Java EE). Tematyka prelekcji nawiązuje do kategorii podatności Broken Authentication and Session Management sklasyfikowanej na drugim miejscu zestawienia OWASP Top 10.

### Key Topics - **Fundamenty uwierzytelniania i sesji**: Trzy czynniki uwierzytelniania (co wiesz, co masz, kim jesteś), bezstanowość protokołu HTTP oraz implementacja sesji po stronie serwera aplikacyjnego (często w Javie identyfikowana przez ciasteczko JSESSIONID). - **Wektory ataków**: Ataki typu brute-force (słownikowe, hybrydowe na hasła i klucze sesji), podsłuchiwanie sesji (session sniffing), ataki replay, session fixation (utrwalenie sesji) oraz kradzież sesji (np. przez Cross-Site Scripting lub fizyczny dostęp). - **Bezpieczeństwo haseł**: Zasady konstruowania polityki haseł, bezpieczne przechowywanie w bazie danych (skróty, sól per użytkownik, sekrety globalne) oraz prawidłowa implementacja procedury odzyskiwania hasła. - **Zarządzanie sesją i ciasteczkami**: Ochrona identyfikatorów sesji, unieważnianie sesji, wymagane atrybuty ciasteczek (Secure, HttpOnly, ograniczenia domeny i ścieżki) oraz wymóg ponownego uwierzytelniania przy operacjach krytycznych. - **Frameworki i ochrona infrastrukturalna**: Rozwiązania wbudowane w Java EE, Spring Security oraz Apache Shiro, a także rola systemów IDS, IPS i WAF.

### Technical Details - **Session Fixation**: Atak polega na podesłaniu ofierze linku z ustalonym identyfikatorem sesji. Jeśli serwer zaakceptuje nieznany klucz sesji i nie zregeneruje identyfikatora po poprawnym uwierzytelnieniu użytkownika, atakujący przejmuje dostęp do konta. - **Przechowywanie haseł i kodowanie**: OWASP rekomenduje stosowanie soli per użytkownik wraz z funkcjami skrótu. Prelegent zwrócił uwagę na kwestie kodowania znaków w Javie (np. wywołania `getBytes()` na hasłach z polskimi znakami), co w procesie aktualizacji aplikacji może prowadzić do problemów z logowaniem. - **Obsługa błędów i brute-force**: Odpowiedzi serwera nie powinny zdradzać, czy błędny był login, czy hasło. Szczegółowe komunikaty powinny trafiać wyłącznie do logów serwerowych. Wśród metod mitygacji brute-force wymieniono: wprowadzanie sztucznych opóźnień odpowiedzi, blokowanie kont po nieudanych próbach, czasowe ograniczanie po adresach IP oraz nietypowe loginy. - **Konfiguracja ciasteczek sesyjnych**: Ciasteczka sesyjne powinny mieć ustawiony atrybut `HttpOnly` (uniemożliwiający odczyt z poziomu JavaScriptu) oraz flagę `Secure` (dla połączeń szyfrowanych). Powinny być powiązane ze ścisłą domeną/ścieżką i wygasać wraz z zamknięciem przeglądarki. - **Walidacja po stronie serwera**: Prelegent przestrzegł przed weryfikacją stanu zalogowania wyłącznie po stronie klienta (np. flaga w kodzie JavaScript przesyłana na serwer), co umożliwia ominięcie zabezpieczeń.

### Takeaways - Nie należy implementować własnych mechanizmów kryptograficznych i sesyjnych od zera; należy korzystać ze sprawdzonych frameworków (Java EE, Spring Security, Apache Shiro). - Konieczne jest regularne weryfikowanie używanych bibliotek, frameworków i serwerów aplikacyjnych pod kątem znanych podatności i instalowanie poprawek. - Istotne jest całościowe podejście do bezpieczeństwa: bezpieczne przechowywanie haseł nie ochroni systemu przed innymi podatnościami, takimi jak XSS czy błędy w sterownikach JDBC. - Należy bezwzględnie weryfikować uprawnienia na serwerze, stosować Code Review oraz zadbać o rzetelne logowanie zdarzeń aplikacji.