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,
Ostatnio zdarzyło się coś. Tym czymś był komunikat antywirusa o wykryciu malware na jednym z zaprzyjaźnionych komputerów. Teoretycznie wszystko jest w porządku, malware jakoś wlazł, antywirus go znalazł i usunął. Po sprawie. No dobrze, tylko jak wlazł i czy aby na pewno nic po sobie nie zostawił?
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ść,
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,
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:
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 :)
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!
Mamy problem z szeroko pojętą jakością oprogramowania. My, czyli nasza cywilizacja. Wciąż nie jesteśmy w stanie stworzyć oprogramowania, które nie będzie zawierało błędów. Nie jesteśmy też w stanie wychwycić wszystkich błędów na etapie testowania. I nie, nie chodzi mi tu (tylko) o błędy związane z bezpieczeństwem. Skutki błędów mogą być zarówno spektakularne (np. eksplozja rakiety Ariane 5), jak i tragiczne (np. ofiary śmiertelne źle działającego sprzętu medycznego). Mogą też być ciekawe, ostatnio przeczytałem, że jednym z ograniczeń odchodzących właśnie do historii wahadłowców było to, że misja nie mogła się przeciągać z grudnia na styczeń, choć tu nie wiem, czy jest to błąd, czy “świadome” ograniczenie. Błędem na pewno było zawieszanie Windows przy zbyt dużym uptime: Computer Hangs After 49.7 Days, choć z drugiej strony niewątpliwym sukcesem było osiąganie takiego uptime...
Jakiś czas temu Google udostępniło możliwość logowania się do swoich usług za pomocą uwierzytelnienia dwuskładnikowego. Jedną z możliwości jest wykorzystanie kodów jednorazowych generowanych przez aplikację Google Authenticator (źródła tego projektu można znaleźć tutaj: google-authenticator). Aplikacja ta jest niczym innym, jak programowym tokenem generującym hasła jednorazowe w oparciu o czas lub licznik (więcej szczegółów: HOTP: An HMAC-Based One-Time Password Algorithm).
Google jakiś czas temu wprowadziło +1 button. W ramach eksperymentu dodałem go na blogu, choć nie wiem, czy długo tam zabawi. Ale ja nie o tym... Zdobycie +1 staje się konfiturą, wartością samą w sobie, sposobem na poprawienie swojego rankingu w wynikach wyszukiwania.