Paweł Goleń, blog

Nowa lista, OWASP TOP10 2007 dostępna jest tutaj, wersja poprzednia, datowana na 2004 rok dostępna jest tu.

Na stronie Top 10 2007-Methodology znajdują się informacje dlaczego zmiany zaszły i jak lista z 2004 roku mapuje się na tę z 2007. Lista OWASP TOP10 2007 powstała na podstawie MITRE Vulnerability Trends for 2006, co samo w sobie jest podejściem dość sensownym. Dzięki temu lista nie traci kontaktu z "rzeczywistym światem" i uświadamia osoby z niej korzystające odnośnie tego, co się naprawdę dzieje.

Po drugie OWASP twierdzi, że TOP10 ma się stać listą podatności, nie ataków. To znowu jest sensowne, ale do wykonania nie mam już takiego przekonania. Problem pojawia się po pierwsze w rozróżnieniu od siebie pojęć: zagrożenie (threat), podatność (vulnerability) i atak (attack). Można zacząć od wyjaśnienia znajdującego się na blogu Microsoft Application Threat Modeling w poście What is "Threat". Niby wszystko jest oczywiste, ale weźmy na przykład taki sql injection. Jest to zagrożenie czy podatność? Zagrożenie, które występuje w wyniku braku walidacji parametrów, czy podatność, która prowadzi do ziszczenia się zagrożenia pod tytułem "ujawnienie danych klientów". A może "ujawnienie danych klientów" to skutek zaistnienia scenariusza sql-injection dzięki podatności polegającej na braku walidacji danych wejściowych?

Temat jest o tyle śliski, że choć definicje podatności i zagrożenia są dość dobrze udokumentowane, to ich rozumienie różni się między sobą dość znacznie. OWASP w dokumentach OWASP Guide informuje, że używa metodologii analizy ryzka firmy Microsoft, dlatego też wcześniej odwoływałem się do publikacji tej właśnie firmy i dlatego chyba będę po prostu przyjmował taką definicję: Threats are realized through attacks which can materialize through certain vulnerabilities if they have not been mitigated with appropriate countermeasures. Tutaj pojawia się problem rozróżenienia zagrożenia od jego rezultatów. Czy zawalenie się budynku jest zagrożeniem, czy skutkiem zmaterializowania się zagrożenia jakim jest trzęsienie ziemii? A może to zależy od tego, czego modelowanie dotyczy? Ale chyba zaczynam się powtarzać, więc koniec tego wątku.

Na liście OWASP TOP10 2007 znajdują się:

• A1. Cross Site Scripting
• A2. Injection Flaws
• A3. Malicious File Execution
• A4. Insecure Direct Object Reference
• A5. Cross Site Request Forgery (CSRF)
• A6. Information Leakage and Improper Error Handling
• A7. Broken Authentication and Session Management
• A8. Insecure Cryptographic Storage
• A9. Insecure Communications
• A10. Failure to Restrict URL Access

Z listy natomiast usunięte zostały:

• Unvalidated Input
• Buffer Overflows
• Denial of Service
• Insecure Configuration Management

Jak widać na liście pojawiły się trzy nowe tematy (A3, A5 i A9), dodatkowo wcześniej istniejący jako jeden temat Broken Access Control został rozbity na dwa (A4 i A10). Rzecz jednak nie w tym, co zostało dodane, a co zostało usunięte...

I tutaj dochodzę do tego, co mi się nie podoba. Wcześniej na liście TOP10 Unvalidated Input zajmował zaszczytną, pierwszą pozycję. Obecnie zniknął z listy... Trochę boli również usunięcie Insecure Configuration Management, Buffer Overflows i Denial of Service już mniej, zwłaszcza, że znaczna część aplikacji powstaje w językach, w których wystąpienie buffer overflow jest, co najmniej, mało prawdopodobne.

Zmiana na liście i usunięcie walidacji danych wchodzących do aplikacji bynajmniej nie oznacza, że temat przestaje być istotny. Wprost przeciwnie, został on jednak przeniesiony do sekcji przeciwdziałania. I tutaj mam sporo wątpliwości. Na liście pozostały Injection flaws i (w dodatku na pierwszym miejscu) Cross Site Scripting. Dobrze, a jak powstaje XSS? Przykładowo - jest pole w którym użytkownik ma wpisać nową nazwę dla swojego konta. Według założeń nowa nazwa może składać się z dużych i małych liter, jednak brak walidacji (lub iluzoryczna walidacja po stronie klienta) powoduje, że akceptowane są wszystkie znaki. Dane wpisane przez użytkownika są później wyświetlane na stronach, nie ma jednak kodowania danych wyjściowych. W rezultacie otrzymuje się działający XSS. Czy w takim razie XSS sam w sobie jest podatnością, czy może wynika z faktu, że są inne podatności, brak walidacji danych i brak kodowania?

I tutaj widzę poważne zagrożenie. Gdzie? Aplikacje są dostarczane przez dostawców do klientów. Nie oszukujmy się, klient chce dostać aplikację szybko, tanio i o maksymalnej funkcjonalności, dostawca natomiast chce sprzedać klientowi coś co już ma przy minimalnym wkładzie i maksymalnym zysku. Często klient specyfikuje jedynie wymagania funkcjonalne, a dostawca skupia się na ich spełnieniu inne obszary (np. wymagania niefunkcjonalne, takie jak wydajność czy bezpieczeństwo) traktuje bez należytej uwagi, czesto pokrywając "grubą farbą" by jakoś to wyglądało. W efekcie skrajnie nieefektywny kod jest przykrywany dziwnie dużymi wymaganiami sprzętowymi (dostawca zarzeka się, że wynika to z jego wewnętrznych testów, pytany o wyniki takich testów nie potrafi/nie może/nie chce ich przedstawić). Dziur bezpieczeństwa często nie widać, przynajmniej do czasu, gdy ktoś ich nie znajdzie i nie opublikuje informacji na ich temat.

W swojej pracy byłem zarówno na pozycji klienta jak i w roli konsultanta przeprowadzającego testy bezpieczeństwa. W pierwszej roli bardzo odpowiadała mi poprzednia lista OWASP TOP10. Starałem się, by w umowie znalazł się zapis, że aplikacja będzie zgodna z zaleceniami OWASP Guide oraz, że nie może zawierać podatności z listy OWASP TOP10, a jeśli taka wystąpi jest traktowana jako błąd bezpieczeństwa. Było to chytre zagranie, na które dostawcy dość często się godzili nie mając świadomości tego, co ich czeka. Dostarczany kod oczywiście nie był zgodny z OWASP Guide, co najmniej 5/10 z TOP10 i... ...i tu druga pułapka. Firma, która wykonywała test penetracyjny miała określone zadanie. Zamiast stanąć przed dość abstrakcyjnym zadaniem oceny "bezpieczeństwa aplikacji" miała ocenić zgodność aplikacji z OWASP TOP10. W wyniku testów okazywało się, że aplikacja jest podatna na (i tu lista z OWASP TOP10), dostawca w tej chwili zaczynał "no ale przecież nic się z tym nie da zrobić". I tutaj pułapka - OWASP TOP10. Nie ważne, co się da osiągnąć dzięki wykrytej podatności, podatność musi zostać usunięta. I tutaj dochodzę do sedna - o ile XSS i sql injection są już w miarę dobrze rozumiane raczej usuwane przez dostawców w przypadku ich stwierdzenia, to w przypadku braku walidacji tak nie jest. Dostawca zasłania się argumentacją, że przecież "nie da się zrobić sql injection" albo "nie ma XSS". To prawda. Nie ma. W tej chwili. Ale nie zmienia to faktu, że może pojawić się w przyszłości. Ochrona powinna być wielowarstwowa, obroną przed XSS nie jest tylko kodowanie wyjścia, ale również walidowanie wejścia. Obawiam się, że usunięcie tego punktu z OWASP TOP10 nieco zagmatwa tu sytuację w takim przypadku, gdy rzeczywiście w chwili obecnej nie będzie walidacji danych, ale wszędzie będzie wyjście kodowane. Dostawca może dowodzić, że nie istnieje XSS (choć analogicznie i błędy injection flaws lub malicious file execution) bo jest kodowanie, w związku z czym walidacji danych na wejściu dorobić nie zamierza... A nie zamierza, dlatego, że rozwiązanie musi być spójne i całościowe, co wymaga trochę pracy i niestety jawnie nie zgadza się z założeniem o minimalnym wysiłku dostawcy. Nie ma się czemu dziwić, sam bym się przed tym bronił...

Moja rada - zawrzeć w umowie zgodność z OWASP TOP10 2004 i OWASP TOP10 2007, lub w oparciu o te dwie listy stworzyć własną kompilację 14 punków, przy czym na mojej kompilacji unvalidated input zdecydowanie będzie zajmować pierwszą pozycję, bo choć to niby tylko środek zaradczy, to na tyle istotny, że brak jego zastosowania sam w sobie jest podatnością.