Paweł Goleń, blog

Bardzo wiele zapytań ofertowych dotyczących "audytu bezpieczeństwa" (w rzeczywistości przedmiot zamówienia z audytem ma niewiele wspólnego) zawiera założenie/wymaganie odnośnie zastosowania "metodologii black box". Moim zdaniem w zdecydowanej większości wypadków takie podejście jest błędne, charakteryzuje się wyjątkowo niekorzystnym stosunkiem price/performance, lub mówiąc jeszcze bardziej "profesjonalnie", niskim ROI. Proste pytanie - jakie zalety daje podejście black box? Ja nie jestem w stanie wskazać praktycznie żadnej wartości dodanej takiego podejścia, potrafię natomiast wskazać kilka istotnych jego wad.

No i co się tak gapi? Kozicy nie widział?

A poważnie - nie, nie miałem do tej pory okazji natknąć się na kozicę w Tatrach. Tym razem taka okazja natrafiła się aż dwa razy. W tym raz kozica popisała się biegiem na krechę z Kołowej Czuby w stronę Zadniego Stawu Polskiego.

Najpierw (pewnie już znany) obrazek:

A później tekstowo:

• Theoretical and Practical Password Entropy,
• The science of password selection,

Ponieważ zainteresowanie drugą częścią zadania (Bootcamp IIa: ciąg dalszy zadania) spadło, a ja mam kilka minut czasu, opiszę o co w nim chodziło. Jest to prawie rozwiązanie zadania. Prawie, bo rozwiązanie zadania dostępne jest w formie wizualnej: Bootcamp: lesson02a - hint/spoiler.

Warto zapoznać się z udostępnionym ostatnio przez OWASP dokumentem Session Management Cheat Sheet. Zawarte w nim wskazówki warto porównać z wymaganiami zdefiniowanymi w OWASP Application Security Verification Standard, zwłaszcza z rozdziałem V3 - Session Management Verification Requirements.

Z moich doświadczeń wynika, że obecnie większość aplikacji korzysta z wbudowanego we framework mechanizmu sesji. Jest to zresztą pierwsze z wymagań ASVS. Takie podejście jest o tyle dobre, że w większości przypadków standardowa obsługa sesji jest po prostu wystarczająco dobra. Mimo wszystko pewne problemy wciąż się powtarzają, w szczególności:

• brak zmiany cookie po uwierzytelnieniu (lub "after reauthentication"),
• brak ochrony cookie przy pomocy flag Secure i httpOnly,
• brak ograniczenia ścieżki, do której wysyłane jest cookie,
• brak wygasania sesji po określonym czasie bezczynności,
• brak niszczenia sesji po wylogowaniu,
• przesyłanie identyfikatora sesji bez szyfrowania,
• przesyłanie identyfikatora sesji w query string,
• ujawnianie identyfikatorów sesji (np. w logach),

Mechanizmy związane z uwierzytelnieniem i kontrolą dostępu są po prostu nieskuteczne, jeśli atakujący jest w stanie ustalić lub wykraść prawidłowy identyfikator sesji ofiary.

Dodatkowo warto pamiętać również, że:

• reguły same-origin policy dla rożnych elementów (cookie, DOM, JavaScript, XMLHttpRequest) nieco różnią się między sobą,
• sesja jest (często) dobrem wspólnym - dwie różne aplikacje na jednym serwerze mogą wzajemnie "brudzić" swoje sesje,

I w ramach bonusu: How and why session IDs are reused in ASP.NET.