Jak NIE należy implementować ochrony przed CSRF
Na początek odsyłam do postu na BugTraq: Hacking CSRF Tokens using CSS History Hack. W szczególności do sekcji Some of the prerequisites for this attack to work (...). Sam atak jest ciekawy, ale te wymagania...
Szczerze mówiąc w żadnej z testowanych aplikacji nie spotkałem się z aż tak zepsutym mechanizmem ochrony przed CSRF. Raczej mogę powiedzieć, że z ochroną przed CSRF nie spotykam się wcale (niestety wciąż zbyt częsta sytuacja) LUB jest ona dobrze zrobiona, choć nie zawsze świadomie. Jest jeszcze stan pośredni, gdy ochrona przed CSRF występuje poniekąd “przy okazji” przykładowo z uwagi na występowanie numeru sekwencyjnego (przy mocno obleganych serwisach trafienie we właściwą wartość wcale nie jest tak trywialne, jak mogłoby się to wydawać, zwłaszcza jeśli istnieją dodatkowe ograniczenia) lub innych parametrów, których wartości nie są łatwe do przewidzenia.
Jeśli wykorzystywany jest token, to wygląda on jak wyjście funkcji SHA1 (przynajmniej pod względem długości), jest losowy (w próbce 20 000 elementów losowość jest szacowana na > 100 bitów) i jest unikalny dla każdego żądania. Jeśli token jest jednorazowy, to typ żądania w zasadzie nie ma większego znaczenia, ale zwykle jest to jednak POST.
Czy ktoś z Was spotkał się z aplikacją, która spełnia “wymagania” tego ataku?
Oryginał tego wpisu dostępny jest pod adresem Jak NIE należy implementować ochrony przed CSRF
Autor: Paweł Goleń