Glosariusz XSS (Cross-Site Scripting)

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 te skrypty są napisane w 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 wykonaniem działań bez zgody użytkownika.

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

plexicus-xss-attack-ilustration

Jak działa XSS?

XSS często atakuje aplikacje webowe, które nieprawidłowo sprawdzają i oczyszczają dane wejściowe użytkowników.

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

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

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

Dlaczego XSS jest ważny 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ę Document Object Model (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 odbijany 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ściowe: 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 Treści (CSP): ogranicza, jakie skrypty mogą być wykonywane w przeglądarce.
  • Unikaj eval() i JavaScriptu w linii: aby zmniejszyć ryzyko wstrzyknięcia.
  • 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 przeglą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 i (c) replikował się na stronach profili 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ł na nieprzetworzone HTML/atrybuty w polach profilu, umożliwiając wykonanie przechowywanych skryptów w przeglądarkach odwiedzających.

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

Powiązane terminy

Kolejne kroki

Gotowy, aby zabezpieczyć swoje aplikacje? Wybierz swoją ścieżkę do przodu.

Dołącz do ponad 500 firm, które już zabezpieczają swoje aplikacje z Plexicus

SOC 2 Compliant
ISO 27001 Certified
Enterprise Ready