Paweł Goleń, blog

Najpierw (pewnie już znany) obrazek:

A później tekstowo:

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

Oryginał tego wpisu dostępny jest pod adresem Obrazkowo o hasłach

Autor: Paweł Goleń

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.

Oryginał tego wpisu dostępny jest pod adresem OWASP: Session Management Cheat Sheet

Autor: Paweł Goleń

Widzę, że po wczorajszej aktualizacji zadania kolega, który poradził sobie z pierwszą częścią zadania, usilnie próbuje poradzić sobie i z drugą, przy pomocy bruteforce. Z tego co widzę “już” jest/był na etapie 9182, czyli gdzieś tak w połowie drogi. Tylko w kolejnej części zadania mogę dać identyfikator o długości 16, 32, (...), 256, 512, 1024, (...), 4096 znaków. Nie tędy droga. A jeśli już bruteforce, to jednak trochę z głową :)

W ramach podpowiedzi/przypomnienia:

• bruteforce można zamknąć w 256 żądaniach, niezależnie od długości identyfikatora,
• wystarczą dwa żądania, do odczytania wiadomości,
• wystarczy jedno żądanie, by w drugim wysłać dowolnie wybraną wartość,

Jeszcze raz, powodzenia!

Oryginał tego wpisu dostępny jest pod adresem Bootcamp IIa: nie, nie chodzi o bruteforce

Autor: Paweł Goleń

Co najmniej dwie osoby poradziły sobie z zadaniem (patrz: Vansel, z drugą rozmawiałem). Gratulacje! Ale teraz pora nieco skomplikować warunki zadania. Należy:

• odczytać wiadomość o identyfikatorze 91827364,
• zrobić to maksymalnie dwoma odwołaniami do serwera,
• XSS będzie wisienką na torcie,

Powodzenia!

Oryginał tego wpisu dostępny jest pod adresem Bootcamp IIa: ciąg dalszy zadania

Autor: Paweł Goleń

Nie jestem takim stachanowcem jak Gynvael, ale też i u mnie (bardzo) drobne nowości w dziedzinie videocastów się pojawiły. Aktualnie są dwie playlisty:

• Bootcamp: Bezpieczeństwo Aplikacji Internetowych,
• Różne,

Będę się starał, by każdy z moich videocastów mieścił się w 15 minutach (10-15 minut). Z jednej strony te 15 minut jest ograniczeniem poniekąd wymuszonym, ale doszedłem do wniosku, że trzymanie się w tym czasie jest niezłym ćwiczeniem dla mnie , więc spróbuję się go trzymać. Zobaczymy jak to będzie sprawdzać się w praktyce :)

Obiecany hint do Bootcamp IIa w odcinku na temat kontroli dostępu do danych.

Oryginał tego wpisu dostępny jest pod adresem Nowe videocasty i hint do bootcampa

Autor: Paweł Goleń

Dziś nowy/stary bootcamp. Jest to zmodyfikowana wersja przykładu opisanego tutaj: Lekcja 2: Nieprawidłowa kontrola dostępu do danych. Celem ćwiczenia jest uzyskanie dostępu do danych, które w założeniu autora aplikacji mają pozostać niedostępne. W szczególności chodzi o znalezienie jednej konkretnej wiadomości, która zawiera pewien tajny kod. To tyle, jeśli chodzi o szczegóły zadania, przynajmniej na razie. Powodzenia!

Przykład dostępny jest pod adresem: http://bootcamp.threats.pl/lesson02a/.

Oryginał tego wpisu dostępny jest pod adresem Bootcamp IIa: Kontrola dostępu do danych

Autor: Paweł Goleń