Temat bezpieczeństwa aplikacji internetowych oraz ich testów penetracyjnych poruszałem już wielokrotnie. Tym razem trochę refleksji.
Depresja pentestera
Jeśli ktoś zadał sobie trud przeczytania mojej serii o testach penetracyjnych wie już, że przy takim podejściu testy takie to ciężka, metodyczna, często monotonna praca, która często przynosi umiarkowany efekt (w sensie małej ilości wykrytych podatności). Czasami z kolei podatności jest tak dużo, że po prostu nie chce się testować, znalezienie dziesiątej wersji tego samego SQL Injection czy 124 XSS nie jest już zabawne... I tu właśnie dochodzę do tytułowej depresji pentestera.
To, co mnie boli, to brak sprzężenia zwrotnego między wynikami testów penetracyjnych, a jakością (i bezpieczeństwem) kolejnych aplikacji (lub kolejnych modułów tej samej aplikacji) tworzonych przez tego samego dostawcę. Jeśli w dalszym ciągu znajdowane są tego samego typu podatności wynikające dokładnie z tych samych powodów, to oznacza to, że dostawca nie traktuje poważnie bezpieczeństwa swoich aplikacji, co wprost przekłada się na bezpieczeństwo swoich klientów (i klientów swoich klientów). Usuwane są jedynie podatności wskazane w raporcie (na przykład jedynie wskazane braki walidacji lub encodingu), nie są w żaden sposób zmieniane praktyki programistyczne. O sytuacji, w której programiści dostawcy w trakcie poprawy błędu analizują przyczyny jego powstania a następnie wyszukują i poprawiają inne miejsca gdzie może on wystąpić (przypominam, że testy penetracyjne nie gwarantują znalezienia wszystkich podatności), można jedynie pomarzyć. Zamiast tego stosowana jest praktyka przyklejania łatek, w dodatku często nieskutecznych, lub co najmniej dziwnych (usunięcie podatności w funkcji zabezpieczającej przez ...usunięcie tej funkcji).
Dlaczego tak się dzieje? W pewnym stopniu jest to zupełnie zrozumiałe. Sam jestem zwolennikiem rozwiązań wystarczająco dobrych w miejsce rozwiązań idealnych (w domyśle - urojonych). Czy to oznacza, że dziurawa aplikacja internetowa może być rozwiązaniem wystarczająco dobrym? Okazuje się, że tak. Jak zwykle punkt widzenia zależy od punktu siedzenia. Dla mnie, osoby o nieco większym niż przeciętny stopniu świadomości (pochlebiam sobie) i myśleniu nacechowanym czasami chyba już zbyt dużą dawką paranoi, oczywiście nie. Dla mitycznego zwykłego użytkownika, który jest nieporównywalnie bardziej liczny od osobników w moim typie, już tak. Zresztą w ramach ciekawej lektury polecam:
A jak jest w przypadku dostawcy aplikacji? Chyba jedynym sposobem na wymuszenie zmiany są straty finansowe. Jeszcze kilka lat temu Microsoft był synonimem dziur bezpieczeństwa. Zaczęło to zagrażać pozycji rynkowej tej firmy i... stał się cud. Nie, nie polega on na tym, że produkty Microsoftu pozbawione są błędów (takie produkty nie istnieją), ale na tym, że zmieniło się podejście korporacji do tematu bezpieczeństwa, coraz częściej pojawiał się termin trustworthy (oczywiście związany z Trustworthy Computing). Tak samo podoba mi się podejście OpenBSD, na którym przy okazji widać, że funkcjonalność i bezpieczeństwo nie idą ze sobą w parze (w sensie - produkt wyjściowy jest kompromisem miedzy bezpieczeństwem i funkcjonalnością).
Wracając do Microsoftu, to zmiana w podejściu nastąpiła dopiero wtedy, gdy kiepska jakość produktów zaczęła powodować ryzyko strat finansowych z powodu odejścia klientów. I to jest chyba jedyna metoda, by firmę nastawioną na zysk (dostawcę aplikacji internetowych) zmusić do bardziej dynamicznych działań mających eliminować przyczyny problemu (bezpieczeństwa), a nie szpachlowania ewidentnego grata. Innymi słowy - klienci muszą zagłosować nogami. Problem w tym, że często nie mają takiej możliwości. W niektórych przypadkach firm (dostawców) oferujących konkretne typy aplikacji na rynku jest jedynie kilka, przy czym funkcjonalność tych aplikacji jest często bardzo różna. Klientów (końcowych) trzeba jakoś przyciągnąć do siebie, a więc należy zaproponować im system o największej funkcjonalności. Wtedy nagle okazuje się, że dostawca do wyboru jest tylko jeden. Głosowanie nogami nie może mieć miejsca, bo po prostu nie ma innego dostawcy, do którego można pójść. Natomiast klienci (końcowi) chętnie zagłosują nogami kierując się swoją własna korzyścią (a nie jakością kodu czy doskonałością techniczną wykorzystanego rozwiązania). Na przykład banki mając do wyboru więcej klientów czy bezpieczniejszy system bankowości elektronicznej wybiorą... więcej klientów, oczywiście zachowując należytą staranność, na przykład poprzez regularne okresowe testy systemu bankowości elektronicznej, czy testy każdej nowej funkcjonalności. W rezultacie łatany system jest wystarczająco dobry. Tylko biedny pentester wpada w depresję, gdy testuje piąte wdrożenie tego samego systemu, znajdując te same błędy w tych samych miejscach... W rezultacie dla odreagowania zajmuje się tamagotchi albo hakuje przez USB...
Tyle, ze tu potrzebna jest wiedza nie tylko programistow, ale przede wszystkim uzytkownikow, a dalej ich klientow ...
A gdzies w tym "lancuchu pokarmowym" jest pentester, ktory jak widac czuje sie ofiara tego kompromisu ...