haker.info | Etyczny hacking |

haker.info  — Etyczny hacking

 Podatność CSRF/XSRF w aplikacjach webowych

27 sierpnia 2019 godz. 13:24    Dawid Farbaniec    450 słów

1. Słowem wstępu

odatność określana skrótem CSRF (czasem XSRF), która występuje w aplikacjach webowych polega na fałszowaniu żądania poprzez złośliwą stronę tak, aby na docelowej witrynie wykonała się niezamierzona przez użytkownika akcja. Jeśli użytkownik odwiedza zamierzoną stronę www, a np. w nowej zakładce przeglądarki otworzy złośliwy link, to możliwe jest przesłanie żądania do podatnej witryny, korzystając z aktywnej sesji/uwierzytelnienia. Jest to znany i popularny atak, ale nadal można spotkać niezabezpieczone aplikacje czasem z niewiedzy, czasem z niedbałości programisty. W tym wpisie pragnę przybliżyć bardziej szczegółowo błąd typu Cross-Site Request Forgery.

Inne nazwy dla CSRF to: XSRF, Session Riding czy Hostile Linking (z ang. wrogie linkowanie).

2. Błąd CSRF — mechanizm działania

Schemat działania podatności CSRF w najprostszych słowach można opisać za pomocą następującego przykładu:

Użytkownik loguje się do swojego portfela internetowego, który jest witryną bardzo słabo zabezpieczoną i posiada błędy CSRF. Otwiera link do wykonania przelewu w nowej zakładce przeglądarki. Wykonuje transfer wirtualnych monet. Przechodzi z powrotem na pierwszą zakładkę, odświeża witrynę i wirtualnych środków z portfela internetowego ubyło. Akurat nic dziwnego, przecież w drugiej zakładce przeglądarki wykonał przelew.

I właśnie z tej zasady działania korzysta atakujący: Wykonywanie żądań na docelowej witrynie z poziomu drugiej, złośliwej witryny.

Schemat ten przedstawiłem dodatkowo w formie graficznej na rysunku 2.1.

Podatność CSRF - przykład
Rysunek 2.1. Zasada działania ataku CSRF — schemat ogólny

3. Przykładowy scenariusz ataku CSRF (+wideo)

Jeśli aplikacja webowa pozwala operować na danych poprzez metodę GET, to stwarza ogromne zagrożenie, co zaprezentowano na wideo 3.1. Takie niebezpieczne akcje z metodą GET mogą doprowadzić do ogromnych strat szczególnie, gdy np. zalogowany użytkownik ma prawa administratora.

Akcja w aplikacji internetowej, która korzysta z metody GET może być wywołana poprzez złośliwy link:

<a href="https://localhost:44330/Wallet/TransferCoins?name=John&amount=1634">Wyświetl rysunki!</a>

czy nawet niewidoczny obrazek (wtedy samo wejście na stronę wywoła akcję):

<img src="https://localhost:44330/Wallet/TransferCoins?name=John&amount=1634" border="0" width="1" height="1" />

Wideo 3.1. Błąd CSRF w przykładowym portfelu internetowym (metoda GET)

Od razu w tym miejscu należy dodać, że korzystanie tylko z metody POST (zamiast GET) nie chroni przed atakiem CSRF.

Atakujący może stworzyć fałszywy formularz POST, a nawet automatycznie go wysłać przy wejściu na witrynę poprzez JavaScript.
Należy skorzystać z dodatkowego, sprawdzonego zabezpieczenia opisanego w punkcie 4 poniżej.

4. Zabezpieczenie przed CSRF poprzez token

Nie wiem jak inne, ale technologia ASP.NET MVC dostarcza gotowe zabezpieczenie przed błędem CSRF poprzez specjalny token.

Należy pamiętać jedynie, aby:

  • Nie dokonywać operacji na danych poprzez metodę GET
  • Ewentualnie dodać dodatkowe potwierdzenie wysyłane metodą POST (z tokenem!)

Dodanie zabezpieczenia tokenem sprowadza się do dwóch kroków:

  • Do widoku w formularzu dodać @Html.AntiForgeryToken()
  • Do akcji kontrolera dodać atrybut [ValidateAntiForgeryToken]

Powyższe instrukcje przedstawiono dodatkowo na rysunku 4.1.

ASP.NET MVC anti CSRF token
Rysunek 4.1. Zabezpieczenie formularza tokenem przed błędem CSRF — ASP.NET MVC

5. Zakończenie

Dziękuję za czas poświęcony na przeczytanie tego wpisu. Wszelkie pytania, uwagi, opinie można pisać w komentarzach. Pozdrawiam!

Dawid Farbaniec


Tagi:  security  websecurity  asp-net-mvc 

Komentarze czytających



Wszystkie treści umieszczone na tej witrynie są chronione prawem autorskim. Surowo zabronione jest kopiowanie i rozpowszechnianie zawartości tej witryny bez zgody autora. Wszelkie opublikowane tutaj treści (w tym kody źródłowe i inne) służą wyłącznie celom informacyjnym oraz edukacyjnym. Właściciele tej witryny nie ponoszą odpowiedzialności za ewentualne niezgodne z prawem wykorzystanie zasobów dostępnych w witrynie. Użytkownik tej witryny oświadcza, że z zamieszczonych tutaj danych korzysta na własną odpowiedzialność. Wszelkie znaki towarowe i nazwy zastrzeżone zostały użyte jedynie w celach informacyjnych i należą wyłącznie do ich prawnych właścicieli. Korzystając z zasobów witryny haker.info oświadczasz, że akceptujesz powyższe warunki.