Czym jest XSS?

O błędzie Cross-Site-Scripting napisano już zapewne wiele powieści ;) Podatność ta jest też częstym przedmiotem żartów. Osoby zajmujące się niskopoziomowymi problemami związanymi z bezpieczeństwem mają już czasem po prostu dość zalewu informacji o XSS. Jako świeży przykład może tu posłużyć majowy post Tavisa Omandy na liście fulldisclosure, zdradzający szczegóły błędu 0-day na wszystkie Windowsy:

I guess I’m talking to myself, maybe this list is all about XSS now ;)

Niemniej jednak błąd ten znajduje się na wysokiej, trzeciej pozycji najnowszej edycji dokumentu OWASP Top Ten. Warto w takim razie nieco mu się bliżej przyjrzeć.

Istota podatności XSS

Na czym polega istota podatności XSS? Po pierwsze jest to przede wszystkim atak na klienta korzystającego z podatnej webaplikacji (w przeciwieństwie np. do SQL injection, którego głównym celem jest część serwerowa). Po drugie, atak polega na wstrzyknięciu do przeglądarki ofiary fragmentu javascript bądź innego języka skryptowego (np. VBScript), który może być uruchomiony w przeglądarce.

W efekcie, atakujący ma możliwość wykonania dowolnego kodu skryptowego w przeglądarce (nie mylić z uruchomieniem dowolnego kodu w systemie operacyjnym ofiary). W dalszej części tekstu dla uproszczenia będę wspominał tylko o javascript, świadomie pomijając inne możliwości – jak choćby wspomniany vbscript).

Potencjalne skutki wykorzystania

Czym może skutkować wykonanie kodu javascript w przeglądarce ofiary? Warto tu wspomnieć takie możliwości:

• wykradanie cookies (w tym cookies sesyjnych) – tj. de facto przejęcie (zalogowanej) sesji ofiary,
• dynamiczna podmiany zawartości strony www (np. słynne „this site have beed hacked”),
• uruchomienie keyloggera w przeglądarce,
• hostowanie malware-u z wykorzystaniem zaatakowanej aplikacji (np. poprzez użycie tagu iframe).

Swoją drogą, istnieje sporo narzędzi, które w praktyce pokazują różne możliwe negatywne efekty wykorzystania XSS.

Podział błędów XSS

Błędy XSS dzielimy na trzy kategorie:

• Persistent (inna spotykana nazwa: stored) XSS – najbardziej złowroga odmiana, polegająca na umieszczeniu kodu javascript po stronie serwerowej (stąd nazwa – stored). Przykładowo,  atakujący umieszcza javascript w komentarzu pod postem na blogu (np. komentując ten post ;) a komentarz automatycznie jest wysyłany do moderacji. W momencie kiedy moderator odczytuje komentarz, uruchamiany jest automatycznie javascript, który może wykradać cookie sesyjne administratora. W tym momencie atakujący ma dostęp do zalogowanej sesji administracyjnej bez znajomości użytkownika oraz hasła! Taka historia zresztą miała miejsce już spory czas temu w systemie WordPress, gdzie udało mi się zlokalizować dokładnie taką lukę :-)
• Reflected XSS – w tym przypadku kod javascript zaszyty jest w linku, który atakujący przesyła do ofiary. Ofiara po kliknięciu na linka łączy się z aplikacją, przekazując jej nieświadomie fragment HTML zawierający kod wykonujący javascript.  Aplikacja zwraca ofierze (stąd nazwa: reflected) wynik (tj. HTML) zawierający wcześniej podany javascript, powodując wykonanie kodu w przeglądarce.
• DOM Based XSS – rzadziej spotykana postać – opisana tutaj.

Praktyczny przykład

Zobaczmy całość na prostym przykładzie (reflected XSS):

Zielonej ofierze podsyłany jest tutaj link z przykazaniem parametru do aplikacji. Parametr search zawiera wstrzyknięcie javascriptu tagiem <script>. Zobaczmy co dzieje się dalej:

Całość można prześledzić na realnej aplikacji, dostępnej tutaj (czy nie ostrzegałem przed klikaniem „w ciemno”? ;-)

Wyżej widzieliśmy bardzo prosty przykład uruchomienia javascriptu poprzez tag <script>. W jaki sposób wykonać javascript jedynie poprzez odpowiednie manipulacje parametrami do tagu? Na przykład tak:

<img src=tralalala onerror=alert(/xss/)>

Zresztą najrozmaitszych metod jest naprawdę wiele.

Metody ochrony przed XSS

W jaki sposób chronić się przed XSS? Przede wszystkim w odpowiedni sposób filtrować dane przesyłane przez użytkownika – przed ich wyświetleniem w aplikacji. Najczęściej przybiera to formę zamiany pewnych istotnych znaków kontrolnych HTML (głównie mam tu na myśli znaki otwierające / zamykające tagi oraz atrybuty tagu) na encje HTML:

& --> &
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;     
/ --> &#x2F;

Taka filtracja najprawdopodobniej zlikwiduje większość podatności XSS w naszej aplikacji. Warto jednak wspomnieć, że wskazana powyżej metoda ochrony w pewnych przypadkach nie działa – odsyłam tutaj do wcześniej wspomnianego XSS Prevention Cheat Sheet i bardziej złożonych przypadków opisanych w tym dokumencie. W każdym razie, realizacja odpowiedniego filtrowania w złożonej aplikacji nie jest wcale taka prosta jakby się mogło wydawać (stąd też duża liczba aplikacji jest podatna).

Jeszcze inną i zazwyczaj niewiele kosztującą metodą ochrony przed jednym z efektów XSS – tj. wykradaniem cookies – jest zastosowanie parametru HttpOnly dla ciastek sesyjnych.

Konkretne technologie posiadają również własne mechanizmy ochronne – jak choćby request validation w .net.

Pewna ochrona może być równolegle realizowana po stronie klienckiej – jako przykład może służyć dodatek NoScript do Firefoxa, czy wręcz wbudowane w przeglądarki mechanizmy ochrony przed XSS.

Czas na ćwiczenie:

1. Szczegóły statków tutaj mają możliwość wyświetlenia obrazu silnika.

2. Bazując na tej funkcjonalności, przygotuj linka realizującego reflected XSS (np. wyświetlenie popupu javascriptowego z tekstem: XSS).

3. Wystarczy że javascript uruchomi się dla przeglądarki Firefox (idealnie – również dla innych przeglądarek).

4. Jeśli chcesz sprawdzić czy przygotowany przez Ciebie XSS jest poprawny w kontekście tego zadania – wyświetl w popupie ciasteczka (document.cookie).

Odpowiedzi podsyłajcie na adres: sekurak@sekurak.pl z tytułem: hackme XSS.

— michal.sajdak<at>securitum.pl