Paweł Goleń, blog

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śnie brak 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.

Oryginał tego wpisu dostępny jest pod adresem Czy aby na pewno jesteś w stanie to wykorzystać?

Autor: Paweł Goleń