Paweł Goleń, blog

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:

• użytkownik jest zalogowany do aplikacji (i identyfikator sesji przekazywany jest w cookie),
• atakujący może przewidzieć jakie żądanie powinno zostać wygenerowane,

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:

• istnieje,
• zgadza się typ połączenia (flaga Secure),
• zgadza się domena i ścieżka (atrybuty Domain oraz Path),

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.