Testy DoS - potrzebne?

Zanim dojdę do głównego tematu kilka nowinek:
 - na blogu pojawiła się dodatkowa adnotacja odnośnie charakteru mojego bloga - w moim profilu
 - jestem świeżo po kolejnej (dla mnie już trzeciej) edycji warsztatów z testów penetracyjnych aplikacji webowych, wkrótce zapraszam na kolejną!
 - nadal gdy do znajomych mówię "do zobaczenia na CONFidence" część z nich smutno pyta dlaczego zobaczymy się dopiero w przyszłym roku, przypominam, że najbliższa edycja CONFidence już w listopadzie 2009 :-)

Wracając do tematu... atak typu Denial of Service dla aplikacji webowych to ciut inne zagadnienie od tych występujących w pozostałych warstwach szeroko pojętych usług. W pierwszym rzucie można przyglądnąć się stosownej kategorii na wiki OWASPa  - Denial of Service Attack , która naświetla problem na konkretnych przykładach. Pozostaje jednak pytanie jak często pentesterzy sprawdzają czy można przeprowadzić skuteczny atak DoS i czy są o to proszeni? Spotkałem się z różnymi opiniami - niestety większość osób, z którymi poruszałem ten temat sądziła, że DoS zawsze się uda, kwestia przyłożonej siły. W związku z powyższym dość rzadko przeprowadza się takie testy.

Moim zdaniem testy DoS warto przeprowadzać zawsze, ale nie za wszelką cene. Co to oznacza? Że nie ma potrzeby zawsze wykupować botnetu żeby sprawdzić ile dana infrastruktura wytrzyma SYNów/sec czy równoległych slowlorisów tylko zobaczyć jak zachowuje się aplikacja i środowisko, w której pracuje przy podstawowych testach, o których mówi choćby OWASP Testing Guide. Dobrze jest przeprowadzić testy DoS z jednej maszyny/jednego adresu IP aby sprawdzić jak bardzo odporni jesteśmy na jednego napastnika. Wstyd jeśli się okaże, że jeden wystarczy by osiągnąć niedostępność usługi dla pozostałych, prawda? :-)

Poza testami wymienionymi w OWASP Testing Guide proponuję testy wydajnościowe aplikacji. Mogą one pomóc w określeniu miejsc, w których aplikacji odwołuje się do bazy danych i wykonuje na niej kosztowne z punktu widzenia czasu operacje. Szczególnie niebezpieczne będą to miejsca jeśli dostęp do nich jest przed zalogowaniem się do aplikacji - napastnik pozostaje wtedy bardziej anonimowy i nie musi w ogóle posiadać konta. Zwróciłbym jeszcze szczególną uwagę na cache'owanie. Jeżeli wydaje się nam, że zapewniliśmy odpowiedni poziom cache'owania obiektów np. na reverse-proxy i aplikacja nie będzie zawsze odpytywała bazy danych to trzeba się zastanowić czy zmieniając/dodając dodatkowe, unikalne parametry w zapytaniu HTTP odpowiedź będzie nadal z cache'a czy za każdym razem generowana na nowo. Jeszcze innym przykładem, który czasami jest ignorowany to posiadanie ciasteczek. Automat próbujący wykonać DoS aplikacji nie będzie przejmował się ciasteczkami ustawianymi przez nagłówek Set-Cookie, a nawet może próbować go wykorzystać jako wektor ataku. W końcu identyfikatory sesji też są w jakiejś bazie :-)


A jakie doświadczenia z testami typu DoS mają inni?