Thursday, October 15. 2015
Na początek oczywista oczywistość:
Risk = Impact x Likelihood
Załóżmy, że w trakcie testów udaje się znaleźć miejsce, w którym następuje jednocześniebrak walidacji danych wejściowych oraz brak encodingu na wyjściu. Te dwie słabości składają się na podatność - XSS.
XSS jest oczywiście zły, niedobry i można przy jego pomocy zrobić (prawie) wszystko, więc ryzyko jest duże, prawda?
Nie, nie prawda. Jak wygląda drugi czynnik - likelihood? Być może ta obiecująca podatność wcale nie nadaje się do wykorzystania. Na przykład może to być reflected XSS a cała aplikacja może korzystać z losowych tokenów w celu ochrony przed CSRF. Jak w takim przypadku wyglądać będzie scenariusz wykorzystania? Albo co w przypadku, gdy jest to stored XSS, ale widoczny tylko dla tego samego użytkownika, który osadza payload (taki self XSS)? Można osadzić payload przy pomocy CSRF? Tak, chyba, że mamy do czynienia ze scenariuszem wspomnianym wcześniej - tokeny anti-CSRF. To może choć jakiś zaawansowany clickjacking? Ups, jest X-FRAME-OPTIONS.
Oczywiście, może się zdarzyć tak, że kilka podatności złoży się w ładny i realistyczny scenariusz ataku. Na przykład gdzieś token nie jest weryfikowany i zupełnie przypadkiem jest tam również reflected XSS. Ten reflected XSS można później wykorzystać do tego, by osadzić payload na tej formatce, gdzie jest stored XSS i w efekcie okazuje się, że podatność da się wykorzystać. Ale jeśli takiego ciągu nie ma, zastanów się proszę, czy ta konkretna podatność to aby na pewno HIGH.
Pamiętacie jak kilka lat temu jakiś dzieciak pokazywał jak zmienić oceny w dzienniku, tylko mu się wszystko psuło przy odświeżaniu strony?
Z praktyki wiemy jednak, że jeśli brakujący element do pełnego scenariusza ataku się pojawi to mamy poważny problem, pamiętajmy, że uzupełnienie scenariusza zazwyczaj powstaje bez naszej wiedzy przy aktualizacjach kodu. Z praktyki też wiemy, że jeśli obniżymy za bardzo rating błędu albo oznaczymy go jedynie jako słabość czy w ogóle go nie zgłosimy bo przykładowo polityka firmy bo trzymamy się tylko ekploitowalnych błędów to w pewnym momencie zdamy sobie sprawę, że dbamy bardziej o "zgodność" względem firmowych standardów niż o bezpieczeństwo samej aplikacji i danych, albo jeszcze gorzej - zatracimy się w oparach rozmyślań i rozważań o tym jak zgłosić błąd i jak rozlegle go opisać, żeby ludzie nietechniczni mogli zrozumieć dlaczego to takie zawiłe i na tej podstawie ustalić, że nie będzie załatany.
Pytanie czy ma to sens. Osobiście uważam, że czas poświęcony na rozwój wydarzeń w prozie opisu podatności biorąc pod uwagę łatwość załatania błędu można by poświęcić najzwyczajniej na jego załatanie.
Pamiętajmy, że testy penetracyjne nie trwają wiecznie, a rozważania na krawędzi psychologii i reżimu działania firmy odwodzą od prawdziwych problemów - bezpieczeństwa.
Reasumując, jestem zdania, że większość błędów bezpieczeństwa łatwych do załatania jak ustalenie flagi na ciastku czy zrobienie walidacji przeciw XSSom czy iniekcjom SQL to tak prozaiczna i zarazem wtórna rzecz, że ich rating nie powinien być zaniżany albo w ogóle albo znacznie.