Cross-Site Request Forgery to nie (tylko) One-Click

Na temat tego, czym jest Cross-Site Request Forgery napisano już wiele. CSRF załapał się również do OWASP TOP10 2007. Na temat CSRF mówiłem (przez chwilę) na mojej prezentacji dotyczącej zarządzania sesjami w aplikacjach internetowych (patrz też na wiki).

Koncepcja CSRF jest prosta – atakujący zmusza atakowanego do wykonania określonego żądania HTTP, które wywołuje określoną akcję w aplikacji. Atak kończy się powodzeniem, jeśli:

Atakowany użytkownik musi być uwierzytelniony w aplikacji, co jest oczywiste. Dlaczego identyfikator sesji musi być przekazywany w cookie? Wynika to z obsługi cookie przez przeglądarkę – po prostu cookie zostanie wysłane do serwera zawsze , jeśli:

Co ciekawe atak CSRF ma mniejsze szanse powodzenia, jeśli identyfikator sesji przekazywany jest w URL (URL rewriting) lub w parametrze żądania. Wynika to z faktu, że identyfikator sesji powinien być wartością losową, a więc umieszczenie go w URL powoduje, że atakujący nie jest w stanie przewidzieć (do końca) jak odpowiednie żądanie powinno wyglądać, czyli spełnić drugi z wymienionych warunków, choć istnieją sytuacje, kiedy jednak będzie mógł to zrobić (Myspace CSRF and XSS Worm (Samy)). Co do zasady jednak ochroną przed CSRF jest użycie pewnego losowego tokenu (np. CSRF Guard).

Ja chciałem zwrócić uwagę na jedno błędne założenie, które jest związane z CSRF i które poniekąd wynika z określenia tego typu ataku jako one-click attack. Nie jest tak, że operacje, które składają się z więcej niż jednego kroku z definicji nie są podatne na CSRF. Dla atakującego nie robi większej różnicy, czy sfałszować musi jedno, czy kilka żądań HTTP. Co najwyżej musi zadbać o to, by żądania były wykonywane we właściwej kolejności, a czasami (w przypadku wolnych aplikacji) – z właściwym opóźnieniem.

Oryginał tego wpisu dostępny jest pod adresem Cross-Site Request Forgery to nie (tylko) One-Click

Autor: Paweł Goleń