Paweł Goleń, blog

Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o "autorski, profesjonalny CMS", to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.

Co do zasady wykorzystanie pewnej dodatkowej "warstwy abstrakcji" ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:

• ta "warstwa abstrakcji" może być źle użyta,
• w wykorzystanym rozwiązaniu mogą być błędy,

I tak właśnie jest w przypadku Ruby on Rails: SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) (patrz też: Rails 3.2.10, 3.1.9, and 3.0.18 have been released!).

A teraz pytania, które zadawałem programistom na szkoleniu, i na które odpowiedź brzmiała zwykle "nie":

• czy jesteś w stanie wymienić wszystkie biblioteki, z których korzysta Twoja aplikacja,
• czy śledzisz informacje o nowych wersjach wykorzystanych bibliotek,
• czy jesteś pewny, że są one aktualne,

Pojęcie "biblioteki" jest tutaj pewnym placeholderem. Patrz też: Remember the Giblets! i The Trouble with Giblets.

Błąd w takim "dodatku" nie jest błędem w Twoim kodzie, ale jest błędem w Twojej aplikacji. Jeśli używasz cudzego kodu, musisz o niego dbać (On handling your pets and a CSRF protection that wasn't). Absolutne minimum to:

• wiedzieć co się użyło (a wybierać rzeczy do użycia też trzeba z głową!),
• śledzić informacje na temat użytych elementów,

A co, kiedy ktoś mówi "nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał"? Cóż, z tym też można sobie poradzić: Test-driven development.

Na początek odsyłacz do "materiału poglądowego": Hacking an Android Banking Application. Chodzi mi szczególnie o sekcję "Memory dump analysis", choć nie tylko. Na potrzeby tego krótkiego wpisu jednak ograniczmy się do tego scenariusza.

A teraz fragment zdania, które w stosunkowo często pojawia się w książkach Schneiera:

If (...), you already have much bigger problems.

A teraz temat do przemyśleń - jeśli atakujący dysponuje takim dostępem do urządzenia ofiary, że jest w stanie pozyskać i analizować zrzut pamięci, to czy przypadkiem nie znaczy to, że mamy już większy problem, niż to, co atakujący w tej pamięci znajdzie?

Załóżmy, że w wyniku błędu w aplikacji mamy możliwość odczytu dowolnego pliku z serwera, pod warunkiem, że znamy jego nazwę (i oczywiście ścieżkę). Załóżmy, że serwer pracuje pod kontrolą systemu Windows, a aplikacja jest napisana w PHP. Załóżmy dodatkowo, że ciekawe dane znajdują się w sesji użytkownika i bardzo chcemy się do nich dostać.

Czym te "bardzo ciekawe dane" mogą być? Zależy. Jednym z ciekawszych przypadków, które widziałem w ciągu ostatnich 12 miesięcy, była sytuacja, w której w sesji użytkownika był zapisywany jego login i hasło. Działo się tak, ponieważ aplikacja webowa pełniła właściwie tylko rolę GUI do WS, który to WS z kolei wymagał podania danych uwierzytelniających przy wywołaniu każdej metody. Możliwość masowego odczytywania danych zapisanych w sesji niewątpliwie w tym przypadku byłaby bardzo "owocna" dla atakującego.

To jak, damy radę się dostać do tych konfitur?

Chodzi oczywiście o to jak przechowywać hasła (i potencjalnie inne dane uwierzytelniające) w systemie tak, by były bezpieczne. Odpowiedź na to pytanie powtarzana jest jak mantra:

Hasła powinny być hashowane z użyciem kosztownego obliczeniowo algorytmu (np. scrypt, bcrypt, PBKDF2), należy do tego użyć unikalny dla każdego hasła salt i opcjonalny pepper. Szyfrowanie jest złe, bo w systemie musi być przechowywany klucz i atakujący, który uzyska dostęp do klucza będzie w stanie rozszyfrować wszystkie hasła przechowywane w bazie.

I wszystko się zgadza. Prawie.