Articles

XSS vs CSRF

W tym rozdziale wyjaśnimy różnice pomiędzy XSS i CSRF oraz przedyskutujemy, czy tokeny CSRF mogą pomóc w zapobieganiu atakom XSS.

Jaka jest różnica między XSS i CSRF?

Cross-site scripting (lub XSS) pozwala atakującemu na wykonanie dowolnego skryptu JavaScript w przeglądarce użytkownika będącego ofiarą.

Cross-site request forgery (lub CSRF) umożliwia atakującemu nakłonienie użytkownika-ofiary do wykonania działań, których nie zamierza wykonać.

Konsekwencje luk XSS są na ogół poważniejsze niż w przypadku luk CSRF:

  • CSRF często odnosi się tylko do podzbioru akcji, które użytkownik jest w stanie wykonać. Wiele aplikacji implementuje ogólne mechanizmy obronne CSRF, ale pomija jedną lub dwie akcje, które pozostają odsłonięte. Z drugiej strony, udany exploit XSS może zazwyczaj skłonić użytkownika do wykonania dowolnej akcji, którą jest on w stanie wykonać, niezależnie od funkcjonalności, w której pojawia się luka.
  • CSRF może być opisany jako luka „jednokierunkowa”, ponieważ atakujący może nakłonić ofiarę do wysłania żądania HTTP, ale nie może pobrać odpowiedzi z tego żądania. I odwrotnie, XSS jest „dwukierunkowy”, ponieważ wstrzyknięty skrypt atakującego może wysyłać dowolne żądania, odczytywać odpowiedzi i przenosić dane do zewnętrznej domeny wybranej przez atakującego.

Czy tokeny CSRF mogą zapobiec atakom XSS?

Niektórym atakom XSS rzeczywiście można zapobiec poprzez efektywne wykorzystanie tokenów CSRF. Rozważmy prostą, odbitą lukę XSS, która może być trywialnie wykorzystana w ten sposób:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

Załóżmy teraz, że podatna funkcja zawiera token CSRF:

https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>

Zakładając, że serwer poprawnie weryfikuje token CSRF i odrzuca żądania bez ważnego tokena, to token zapobiega wykorzystaniu luki XSS. Wskazówka jest tu zawarta w nazwie: „cross-site scripting”, przynajmniej w swojej odzwierciedlonej formie, wiąże się z żądaniem cross-site. Uniemożliwiając atakującemu sfałszowanie żądania cross-site, aplikacja zapobiega trywialnemu wykorzystaniu luki XSS.

Pojawiają się tu pewne ważne zastrzeżenia:

  • Jeśli odbita luka XSS istnieje gdziekolwiek indziej w witrynie w ramach funkcji, która nie jest chroniona przez token CSRF, wówczas ta luka XSS może zostać wykorzystana w normalny sposób.
  • Jeśli podatność XSS istnieje w dowolnym miejscu na stronie, może zostać wykorzystana do wykonania akcji przez użytkownika będącego ofiarą, nawet jeśli te akcje są chronione przez tokeny CSRF. W takiej sytuacji, skrypt atakującego może zażądać odpowiedniej strony w celu uzyskania ważnego tokena CSRF, a następnie użyć tego tokena do wykonania chronionej akcji.
  • Tokeny CSRF nie chronią przed przechowywanymi podatnościami XSS. Jeśli strona, która jest chroniona przez token CSRF, jest również punktem wyjścia dla przechowywanej luki XSS, wówczas ta luka XSS może zostać wykorzystana w zwykły sposób, a ładunek XSS zostanie wykonany, gdy użytkownik odwiedzi stronę.