Ten artykuł jest częścią serii o zagrożeniu XSS:

1. Co to jest XSS?
2. Wykrywanie XSS
3. Automatyczne wykrywanie XSS
4. Zabezpieczenie przed XSS

W tym artykule przyjrzymy się dokładniej jednemu z najpopularniejszych (choć jednocześnie jednemu z prostszych) zagrożeń w stosunku do aplikacji webowych. Jest to atak typu XSS – Cross Site Scripting. Znalazł się on nawet na liście najczęściej występujących podatności w aplikacjach webowych OWASP TOP 10 (na miejscu 7). Ale Co to jest XSS

Na czym polega XSS?

Atak Cross Site Scripting w dużym uproszczeniu polega na wstrzyknięciu złośliwego kodu do atakowanej aplikacji, żeby wykonać go na przeglądarce użytkownika. Obrazuje to następujący diagram.

Widać tu, że atakujący znajduje sposób, żeby zmodyfikować stronę, którą wyświetli zwykły użytkownik. W ten sposób użytkownik nadal będzie korzystał z normalnej aplikacji, co do której ma zaufanie i która jest zabezpieczona certyfikatem HTTPS. Nie będzie się on spodziewał, że taka aplikacja może uruchomić złośliwy kod.

Przykłady zagrożeń

Co nam wobec tego grozi? Największym zagrożeniem związanym z XSS jest fakt, że dzięki wykorzystaniu tego rodzaju podatności atakujący może wywołać kod JavaScript na przeglądarce dowolnego użytkownika w kontekście aplikacji, do której ten ma zaufanie. Dzięki temu złośliwy kod może mieć dostęp do danych aplikacji przechowywanych po stronie przeglądarki. W tym do ciasteczek i localStorage, w których to miejscach zazwyczaj przechowywane są wrażliwe dane, takie jak access token umożliwiający operacje na API w ramach naszego konta. 

Jakie są wobec tego możliwości wykorzystania XSS przez atakującego?

• kradzież tokenu autoryzującego, równoważna z przejęciem dostępu do konta. 
  Gdy ktoś uzyska dostęp do tokenu lub ciasteczka autoryzującego, to tak jakby przejął nasze konto. W wielu przypadkach wystarczy bowiem przenieść taki token do swojej przeglądarki i już można korzystać z danej aplikacji (nawet nieznająca hasła) do czasu aż użytkownik pozostaje zalogowany w tej sesji.

• podmiana zawartości strony internetowej
  Dzięki możliwości wykonania dowolnego kodu Java Script po stronie innego użytkownika, atakujący ma możliwość swobodnej modyfikacji struktury i treści strony internetowej. W ten sposób może wyświetlić różne komunikaty, które będą miały na celu zachęcenie użytkownika do ryzykownego zachowania. Podobnie jak to ma miejsce w phishingu, jednak treść ta wyświetla się w zaufanym miejscu. Na przykład na stronie głównej LinkedIn.
  

• uruchomienie keyloggera
  W ten sposób atakujący może przejąć hasło lub inne dane wrażliwe.Przykład widać tutaj https://github.com/hadynz/xss-keylogger

• przekierowanie użytkownika na inną stronę. 
  Można nawet przekierować automatycznie użytkownika pod zupełnie inny adres (np. https://liinkediin.com, który wygląda niemalże identycznie jak oryginalny adres. Może to skutkować dalszymi wyłudzeniami (danych bądź akcji).

• wymuszenie nieświadomego wykonania akcji. 
  Można w ten sposób również spowodować, że ktoś opublikuje post reklamowy na swoim koncie np. Facebook, nie będąc tego świadomym.

Rodzaje XSS

Wyróżniamy 3 główne rodzaje podatności XSS. Każdy z nich działa w ten sam sposób. Atakujący powoduje uruchomienie złośliwego skryptu po stronie aplikacji zwykłego użytkownika. Jednak różnią się one źródłem złośliwych danych.

Dla uproszczenia przy analizie zagrożeń warto założyć, że każde miejsce w aplikacji, w którym tekst wprowadzony przez jednego użytkownika jest w jakiś sposób widoczny dla innego użytkownika, może być potencjalnym miejscem na wykorzystanie Cross Site Scriptingu.

Reflected XSS

Najprostszą metodą na przekazanie złośliwego kodu JavaScript inemu użytkownikowi jest wysłanie go do strony w URLu – za pomocą query parameters.

Aplikacja jest podatna na tego rodzaju atak, jeżeli przyjmuje parametry w URLu i wyświetla je bezpośrednio na stronie. Może to się odbywać zarówno podczas generowania po stronie serwera jak i frontendowo.

Jak widać na diagramie, atakujący musi najpierw przesłać innym użytkownikom zmodyfikowany URL do podatnej aplikacji. W ogólnym przypadku można by łatwo rozpoznać tego typu dziwny adres (np. https://suvroc.github.io/security-demos/XSS/reflectedXSS.html?name=%3Cscript%3Ealert(1)%3C/script%3E).
Jednak biorąc pod uwagę, ze każdy taki link może zostać bardzo łatwo skrócony, taki dziwnie wyglądający format może być z łatwością ukryty (np. https://bit.ly/2PLUSn9).

Taki zmodyfikowany link można przesłać komuś mailem, bądź opublikować na stronie internetowej z odpowiednią zachętą do kliknięcia w niego.

Demo
https://suvroc.github.io/security-demos/XSS/reflectedXSS.html
Spróbuj modyfikować wartość query parameter o nazwie name.

• https://suvroc.github.io/security-demos/XSS/reflectedXSS.html?name=test
• https://suvroc.github.io/security-demos/XSS/reflectedXSS.html?name=%3Cscript%3Ealert(1)%3C/script%3E

Stored XSS

W kolejnym typie podatności XSS źródłem złośliwego tekstu jest warstwa persystencji (czyli na przykład baza danych aplikacji).

Aby atak się udał aplikacja musi posiadać 2 elementy:

• miejsce do zapisywania tekstów wprowadzonych przez użytkownika do bazy danych aplikacji, 
• miejsce wyświetlania zapisanych w bazie danych tekstów użytkownikom (innym niż twórca wpisu). 

Przykładem może tu być aplikacja sklepu, w którym zwykły użytkownik – Klient może wpisać dowolny tekst w polu adres bądź imię i nazwisko. Następnie ten tekst będzie wyświetlony w panelu administracyjnym podczas przeglądania listy wszystkich zamówień. Jeżeli taka aplikacja nie byłaby zabezpieczona przed XSS, to każdy użytkownik mógłby wstrzyknąć adminowi złośliwy kod.

Demo
https://suvroc.github.io/security-demos/XSS/storedXSS.html
Spróbuj wpisać w pole tekstowe kolejno różne teksty:

• aaa
• test
• <script>alert(1)</script>
• bbb

Jest to uproszczone demo, w którym persitent storage jest localSotrage, a to oznacza, że wartości są przechowywane pomiędzy odświeżeniami strony, ale nie pomiędzy przeglądarkami.

DOM-based XSS

Ostatni rodzaj XSS jest nieco bardziej wyrafinowany. W tym przypadku źródłem złośliwego tekstu jest element w kodzie strony (w drzewie DOM strony).

W uproszczonej wersji może to być zwykły input, który jest analizowany przez kod JavaScript. jednak w bardziej skomplikowanych scenariuszach możemy chcieć generować kod HTML na podstawie innych danych obecnych na stronie.
Tego typu podatność jest bardzo trudno zidentyfikować, ponieważ wymaga ona przejścia przez każdą ścieżkę funkcjonalną systemu.

Demo
https://suvroc.github.io/security-demos/XSS/DOMbasedXSS.html
Spróbuj wpisać w pole tekstowe następujące teksty (takie jak poprzednio):

• aaa
• test
• <script>alert(1)</script>
• bbb

Zadanie

Jako ćwiczenie na zrozumienie ataku XSS spróbuj przejść kilka zadań z gry łamanie zabezpieczeń XSS takiej jak: https://xss-game.appspot.com

Podsumowanie

W tym artykule dowiedziałeś się czym jest i jak działa atak XSS. Poznałeś również rożne jego rodzaje.Teraz czas na dowiedzenie się, w jaki sposób wyszukiwać tego typu podatności i jak się przed nimi zabezpieczać.