Cross-Site Scripting (XSS) i CSRF

Cross-Site Scripting (XSS) to luka typu injection po stronie klienta, w której atakujący wstrzykuje złośliwe skrypty do stron internetowych wyświetlanych innym użytkownikom. W przeciwieństwie do wstrzyknięcia SQL, którego celem jest serwer, XSS atakuje przeglądarkę ofiary. Gdy przeglądarka renderuje skrypt atakującego, wykonuje go z takimi samymi uprawnieniami jak prawidłowe skrypty strony, co umożliwia przejęcie sesji, kradzież danych uwierzytelniających i dostarczanie złośliwego oprogramowania.

Reflected XSS występuje, gdy złośliwy skrypt zostaje umieszczony w adresie URL, a serwer natychmiast „odsyła” go w odpowiedzi HTTP bez odpowiedniego kodowania. Ofiara zostaje nakłoniona — często za pośrednictwem odsyłacza phishingowego — do kliknięcia spreparowanego adresu URL, co powoduje wykonanie skryptu atakującego w jej przeglądarce. Reflected XSS jest nietrwały — wykonuje się tylko wtedy, gdy ofiara kliknie złośliwy odsyłacz.

Stored (persistent) XSS umieszcza złośliwy skrypt w bazie danych aplikacji — na przykład w komentarzu lub wpisie na forum. Skrypt zostaje wykonany w przeglądarce każdego użytkownika, który wyświetli te treści, dlatego stored XSS jest znacznie groźniejszy niż reflected XSS. DOM-based XSS występuje w całości w przeglądarce, gdy JavaScript po stronie klienta odczytuje dane kontrolowane przez atakującego z modelu DOM (np. fragment adresu URL), a następnie w niebezpieczny sposób zapisuje je z powrotem na stronie.

Podstawowym zabezpieczeniem przed XSS jest kodowanie danych wyjściowych: przed wyrenderowaniem znaków w przeglądarce należy zamienić znaki specjalne na odpowiadające im encje HTML (<, >, &). Nagłówek Content Security Policy (CSP) ogranicza skrypty, które mogą zostać wykonane, zapewniając istotną dodatkową warstwę ochrony. Po stronie serwera należy również stosować walidację danych wejściowych (z użyciem listy dozwolonych wartości).

Cross-Site Request Forgery (CSRF) wykorzystuje zaufanie, jakim witryna obdarza przeglądarkę uwierzytelnionego użytkownika. Atakujący nakłania przeglądarkę ofiary do wysłania niechcianego uwierzytelnionego żądania do witryny, w której ofiara jest zalogowana. Ponieważ przeglądarka automatycznie dołącza pliki cookie sesji, serwer docelowy uznaje żądanie za prawidłowe. Typowe ataki CSRF służą do przekazywania środków, zmiany adresów e-mail lub modyfikowania ustawień konta.

Wyobraźmy sobie, że użytkownik jest zalogowany do swojego banku pod adresem bank.com. Atakujący wysyła mu wiadomość e-mail z ukrytym znacznikiem obrazu: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Po otwarciu wiadomości przeglądarka automatycznie ładuje adres obrazu, wysyłając żądanie przelewu wraz z plikiem cookie sesji bankowej ofiary. Bank przetwarza je jako prawidłowe żądanie.

Najskuteczniejszym zabezpieczeniem przed CSRF jest token CSRF — unikatowa, nieprzewidywalna wartość umieszczana w każdym formularzu i weryfikowana po stronie serwera. Ponieważ atakujący nie może odczytać tokenu z innego źródła (zgodnie z zasadą tego samego źródła), sfałszowane żądania nie zawierają prawidłowego tokenu i są odrzucane. Atrybut pliku cookie SameSite (SameSite=Strict lub Lax) również uniemożliwia przeglądarkom wysyłanie plików cookie w żądaniach między witrynami.

Ataki XSS i CSRF są często mylone, ale mają różne cele. XSS wstrzykuje złośliwy skrypt wykonywany w przeglądarce ofiary, wykorzystując zaufanie użytkownika do witryny. CSRF podrabia żądania wysyłane z przeglądarki ofiary do zaufanej witryny, wykorzystując zaufanie witryny do przeglądarki użytkownika. XSS może posłużyć do kradzieży tokenów CSRF, skutecznie łącząc obie luki w jeden atak.

Flagi plików cookie zapewniają istotne zabezpieczenia przed XSS. Flaga HttpOnly uniemożliwia JavaScriptowi dostęp do pliku cookie za pośrednictwem document.cookie, utrudniając kradzież tokenu sesji nawet w przypadku wystąpienia XSS. Flaga Secure gwarantuje, że pliki cookie będą przesyłane wyłącznie przez HTTPS, zapobiegając ich przechwyceniu w niezaszyfrowanych kanałach. Obie flagi należy ustawiać dla wszystkich plików cookie sesji jako element wielowarstwowej ochrony.

Testerzy bezpieczeństwa wykrywają XSS, wprowadzając testowe ładunki do każdego pola wejściowego, parametru adresu URL, nagłówka HTTP i pola JSON. Prostym testem jest <script>alert(1)</script> — jeśli pojawi się okno alertu, oznacza to potwierdzenie XSS. Narzędzia takie jak Burp Suite automatyzują skanowanie pod kątem XSS, a OWASP ZAP zapewnia bezpłatne skanowanie aktywne. Wykrywanie DOM-based XSS wymaga analizy JavaScriptu po stronie przeglądarki, a nie badania odpowiedzi serwera.

Ataki XSS spowodowały poważne szkody w świecie rzeczywistym. Robak Samy (2005) rozprzestrzenił się w serwisie MySpace w ciągu 20 godzin, wykorzystując stored XSS do samoczynnego zainfekowania ponad miliona profili. Ataki XSS mogą służyć do kradzieży tokenów sesji i całkowitego przejmowania kont, przekierowywania użytkowników do witryn phishingowych, dostarczania exploitów przeglądarkowych (drive-by downloads), a także modyfikowania treści stron w celu wyświetlania wybranym użytkownikom fałszywych informacji.

Sprawdź swoją znajomość zagadnień z CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: XSS wstrzykuje skrypty do stron wyświetlanych innym użytkownikom, CSRF nakłania uwierzytelnione przeglądarki do wysyłania sfałszowanych żądań, a kodowanie danych wyjściowych, CSP, tokeny CSRF i atrybut plików cookie SameSite stanowią podstawowe zabezpieczenia. Następnie omówimy błędy uwierzytelniania i niezabezpieczoną deserializację.