Anatomia Ataku #1 – Cross Site Scripting

Cross-Site Scripting (XSS) to jeden z najpopularniejszych i wykorzystujących najpopularniejsze podatności ataków. Jest uważany za jeden z najbardziej ryzykownych ataków na aplikacje internetowe. Często porównywany z podobnymi atakami po stronie klienta, ponieważ podczas tego ataku najczęściej używane są języki po stronie klienta. Jednak atak XSS jest uważany za bardziej ryzykowny, ponieważ może uszkodzić nawet mniej wrażliwe technologie.

Atak Cross-Site Scripting to wstrzyknięcie złośliwego kodu, który zostanie wykonany w przeglądarce ofiary. Złośliwy kod jest zwykle pisany w językach programowania po stronie klienta, takich jak Javascript, HTML, VBScript, Flash itp. Jednak do przeprowadzenia tego ataku najczęściej używane są Javascript i HTML.

Głównym celem tego ataku jest kradzież danych tożsamości innego użytkownika – plików cookie, tokenów sesji i innych informacji. W większości przypadków ten atak jest wykorzystywany do kradzieży plików cookie drugiej osoby. Jak wiemy, pliki cookie pomagają nam logować się automatycznie. Dlatego za pomocą skradzionych plików cookie możemy zalogować się przy użyciu innych tożsamości. To jeden z powodów, dla których ten atak jest uważany za jeden z najbardziej ryzykownych ataków. W zależności od rodzaju ataku XSS, złośliwy skrypt może:

1. zostać odzwierciedlony w przeglądarce ofiary
2. zapisany w bazie danych i wykonywany za każdym razem, gdy użytkownik wywoła odpowiednią funkcję.

Głównym powodem tego ataku jest nieodpowiednia walidacja danych wejściowych użytkownika, w przypadku której złośliwe dane wejściowe mogą dostać się do danych wyjściowych. Złośliwy użytkownik może wprowadzić skrypt, który zostanie wstrzyknięty do kodu witryny. Wtedy przeglądarka nie jest w stanie stwierdzić, czy wykonywany kod jest złośliwy, czy nie. W związku z tym w przeglądarce ofiary jest uruchamiany złośliwy skrypt lub wyświetlany jest dowolny sfałszowany formularz. Istnieje kilka form, w których mogą wystąpić ataki XSS.

Główne formy Cross Site Scripting są następujące:

1. „Odbity” XSS (Reflected XSS) –  złośliwy skrypt jest wstrzykiwany do zaufanych lub w inny sposób niegroźnych witryn internetowych. Zazwyczaj wstrzyknięcie następuje, gdy niczego niepodejrzewający użytkownik kliknie łącze, które jest specjalnie zaprojektowane do atakowania odwiedzanej witryny. Złośliwe wyniki są zwracane po wprowadzeniu złośliwego kodu. Odbity kod XSS nie jest zapisywany na stałe. W takim przypadku złośliwy kod jest odzwierciedlany w dowolnym wyniku witryny. Kod ataku może być zawarty w fałszywych parametrach adresu URL lub HTTP.
   
   W odbitym ataku XSS aplikacja internetowa z luką XSS pozwoli na wprowadzenie potencjalnie szkodliwych danych do rutynowej transakcji. Na przykład, gdy użytkownik wyśle ​​żądanie sieciowe do serwera, przesyłając formularz, aplikacja odpowie stroną zawierającą echo tego, co użytkownik przesłał do potwierdzenia. Złośliwy fragment kodu JavaScript może zastąpić lub dołączyć się do wpisu użytkownika, który użytkownik nieumyślnie wykonuje. Odbity atak XSS może również skłonić ofiarę do uruchomienia żądania HTTP, klikając złośliwy link w wiadomości e-mail lub fałszywą stronę internetową, która wygląda na wiarygodną.

2. „Przechowywany” XSS (Stored/Persistent XSS) – można uznać za bardziej ryzykowny i zadaje większe obrażenia. W ataku tego typu złośliwy kod lub skrypt jest zapisywany na serwerze WWW (np. w bazie danych) i wykonywany za każdym razem, gdy użytkownik wywoła odpowiednią funkcjonalność. W ten sposób przechowywane ataki XSS mogą mieć wpływ na wielu użytkowników. Ponadto, ponieważ skrypt jest przechowywany na serwerze WWW, będzie miał wpływ na witrynę przez dłuższy czas.
   
   W celu wykonania zapisanego ataku XSS, złośliwy skrypt powinien zostać przesłany przez podatny formularz wejściowy (na przykład pole komentarza lub pole recenzji). W ten sposób odpowiedni skrypt zostanie zapisany w bazie danych i wykonany przy wczytaniu strony lub wywołaniu odpowiedniej funkcji.

3. #DOM XSS (DOM-based/type-0 XSS) –występuje, gdy zmieniane jest środowisko DOM (Document Object Model), ale kod po stronie klienta nie ulega zmianie. Kiedy środowisko DOM jest modyfikowane w przeglądarce ofiary, kod po stronie klienta działa inaczej.
   Przykład:
   
   Weź pod uwagę, że istnieje strona internetowa o adresie URL http://testing.com/book.html?default=1. Jak wiemy, „default” to parametr, a „1” to jego wartość. Dlatego też, aby wykonać atak XSS DOM, jako parametr moglibyśmy przesłać skrypt.

XSS jest uważany za jeden z najgroźniejszych ataków, ponieważ jego głównym celem jest kradzież tożsamości użytkowników serwisu lub systemu. Ponadto ataki XSS mogą być przeprowadzane przy użyciu różnych języków po stronie klienta, takich jak JavaScript, HTML, VBScript, Flash itp. A to sprawia, że ​​są one bardziej szkodliwe i rozpowszechnione niż inne możliwe ataki. Inną rzeczą, która stanowi o ryzyku jakie niesie, jest możliwość zapisania go w serwisie WWW – w ten sposób może on wpłynąć na wielu użytkowników przez dłuższy czas. XSS czasami można wykonać nawet na mniej podatnych systemach, a luki, które wykorzystuje czasami trudne do znalezienia.

Sposoby zapobiegania XSS

Chociaż ten rodzaj ataku uważany jest za jeden z najbardziej niebezpiecznych i ryzykownych, należy przygotować plan zapobiegania. Ze względu na popularność tego ataku istnieje wiele sposobów, aby mu zapobiec.

Powszechnie stosowane metody zapobiegania obejmują:

• Walidację danych – pierwszym krokiem w zapobieganiu temu atakowi jest sprawdzanie poprawności danych wejściowych. Wszystko, co wprowadzi użytkownik, powinno być dokładnie walidowane, ponieważ wejście użytkownika może trafić na wyjście. Walidację danych można nazwać podstawą zapewnienia bezpieczeństwa systemu. Przypominam, że ideą walidacji jest niedopuszczanie do niewłaściwych danych wejściowych.

Inną dobrą metodą zapobiegania jest filtrowanie danych wprowadzanych przez użytkownika. Ideą filtrowania jest wyszukiwanie ryzykownych słów kluczowych w danych wejściowych użytkownika i usuwanie ich lub zastępowanie pustymi ciągami.
Te słowa kluczowe mogą być:

• Tagi <script></script>

• Polecenia JavaScript

• znaczniki HTML

• Usługi analizy statycznej i struktury oprogramowania, które skanują pliki binarne w celu znalezienia i naprawienia usterek. Najczęściej łączy się to z usługami testowania bezpieczeństwa aplikacji dostawcy w celu oceny zagrożeń bezpieczeństwa w aplikacjach innych firm.

• Web Application Firewall – Zapora WAF lub aplikacja internetowa pomaga chronić aplikacje internetowe, filtrując i monitorując ruch HTTP między aplikacją internetową a Internetem. WAF to ochrona warstwy 7 protokołu (w modelu OSI) i nie jest przeznaczona do obrony przed wszystkimi typami ataków. Wdrażając plik WAF przed aplikacją internetową, pomiędzy aplikacją internetową a Internetem umieszczana jest osłona. Podczas gdy serwer proxy chroni tożsamość komputera klienckiego za pomocą pośrednika, WAF jest rodzajem reverse-proxy, chroniącego serwer przed atakiem poprzez filtrowanie żądań klientów przez WAF przed dotarciem do serwera.

Jeżeli spojrzymy na rosnące standardy dotyczące bezpieczeństwa aplikacji – WAF jest absolutnym minimum do wdrożenia przed każdą aplikacją webową, niejednokrotnie jest oferowany jako usługa od Twojego dostawcy hostingu. Jednak już wkrótce standardem staną się aplikacje budowane z myślą security by design – z wbudowanymi filtrami i mechanizmami walidacji, szyfrowaniem danych, kontrolą API etc.