Czym jest XSS (Cross-Site Scripting)?

Cross-Site Scripting, czyli XSS, to luka bezpieczeństwa w witrynach internetowych, która pozwala atakującym na dodawanie szkodliwych skryptów do stron internetowych. Najczęściej skrypty te są napisane w języku JavaScript.

Jeśli ktoś odwiedzi stronę dotkniętą XSS, jego przeglądarka uruchamia skrypt atakującego. Może to skutkować kradzieżą ciasteczek, przejęciem sesji lub działaniami podejmowanymi bez zgody użytkownika.

XSS, podobnie jak SQL Injection, jest regularnie wymieniany w OWASP Top 10 jako jedna z najczęstszych luk w aplikacjach internetowych.

Jak działa XSS?

XSS często atakuje aplikacje internetowe, które nie sprawdzają i nie oczyszczają poprawnie danych wejściowych użytkownika.

Na przykład, jeśli pole komentarza pozwala na surowe HTML lub JavaScript bez żadnego filtrowania, atakujący mógłby dodać taki kod:

<script>alert('Hacked!');</script>

Kiedy ofiary przeglądają stronę, złośliwy kod uruchamia się w ich przeglądarce.

Dlaczego XSS ma znaczenie w cyberbezpieczeństwie

XSS może prowadzić do większego naruszenia:

• Przejęcie konta (kradzież ciasteczek sesji w celu podszycia się pod użytkowników)
• Kradzież danych (przechwytywanie danych z formularzy, takich jak hasła czy karty kredytowe)
• Ataki phishingowe (wstrzykiwanie fałszywych formularzy logowania)
• Dostarczanie złośliwego oprogramowania (przekierowywanie użytkowników na złośliwe strony)

Rodzaje XSS

1. DOM-Based XSS
2. Atak odbywa się całkowicie w przeglądarce poprzez manipulację Modelem Obiektowym Dokumentu (DOM) bez angażowania serwera.
3. Stored XSS
4. Złośliwy skrypt jest trwale przechowywany na serwerze, na przykład w bazie danych, na stronie profilu.
5. Reflected XSS
6. Skrypt jest odbity od serwera internetowego (np. w URL lub komunikacie o błędzie), skrypt zostanie wykonany, gdy ofiara kliknie spreparowany link przez atakujących.

Jak zapobiegać XSS

• Sanityzacja danych wejściowych i kodowanie wyjścia: zawsze oczyszczaj dane wejściowe użytkownika przed ich przetworzeniem, przekształcając dane wejściowe użytkownika w bezpieczny format
• Używaj Polityki Bezpieczeństwa Zawartości (CSP): ogranicza, jakie skrypty mogą być wykonywane w przeglądarce.
• Unikaj eval() i JavaScriptu w linii: aby zmniejszyć ryzyko iniekcji.
• Testowanie bezpieczeństwa (DAST/IAST): przeprowadzaj testy bezpieczeństwa, aby wcześnie wykrywać podatności

Przykład w rzeczywistym przypadku - Robak Samy (MySpace, 2005)

Co się stało: Samy Kamkar opublikował profil na MySpace, który zawierał ładunek stored XSS. Gdy inni użytkownicy oglądali profil, ładunek uruchamiał się w ich przeglądarkach, (a) dodawał Samy’ego jako przyjaciela, (b) dodawał frazę „Samy is my hero” do ich profili, oraz (c) replikował się na strony profilowe tych użytkowników.

Wpływ: Robak samopropagował się do ~1 miliona użytkowników w ciągu ~20 godzin, zmuszając MySpace do tymczasowego wyłączenia.

Dlaczego to zadziałało: MySpace pozwalało na nieprzetworzone HTML/atrybuty w polach profilu, umożliwiając wykonanie przechowywanego skryptu w przeglądarkach odwiedzających.

Lekcje / naprawa: Prawidłowe kodowanie wyjściowe, sanitacja danych wejściowych, usunięcie HTML w polach profilu oraz szybkie łatanie. Samy później stanął przed konsekwencjami prawnymi, a MySpace wdrożył filtry.

Powiązane terminy

• SQL Injection
• DAST (Dynamic Application Security Testing)
• OWASP Top 10
• CSRF (Cross-Site Request Forgery)