XSS w React: dangerouslySetInnerHTML i skrypty zewnętrzne

React automatycznie escapuje wszystkie wartości renderowane przez JSX przed wstawieniem ich do DOM. Gdy w JSX zapisują Państwo {userInput}, React wykonuje operację równoważną przypisaniu do textContent — wartość jest traktowana jako tekst, nigdy jako HTML. Domyślnie zapobiega to większości ataków XSS w aplikacjach React.

dangerouslySetInnerHTML={{ __html: htmlString }} to mechanizm Reacta omijający automatyczne escapowanie. Nazwa celowo brzmi alarmująco: informuje, że biorą Państwo odpowiedzialność za bezpieczeństwo ciągu HTML. React bezpośrednio ustawia innerHTML, interpretując dowolny HTML, w tym skrypty i procedury obsługi zdarzeń.

Rzeczywiście potrzebują Państwo dangerouslySetInnerHTML, gdy renderują HTML pochodzący z edytora tekstu sformatowanego (takiego jak TipTap lub Quill), systemu CMS przechowującego HTML albo konwertera Markdown na HTML. Źródła te generują prawdziwe znaczniki HTML, które muszą zostać wyrenderowane jako HTML, a nie jako escapowany tekst.

Jeśli ciąg HTML zawiera <script>stealCookies()</script> lub <img src=x onerror="stealData()">, ustawienie go jako innerHTML powoduje wykonanie kodu atakującego. Każda treść pochodząca od użytkownika, przekazana bezpośrednio do dangerouslySetInnerHTML bez sanityzacji, stanowi krytyczną lukę XSS.

DOMPurify to standardowy w branży sanityzator HTML dla przeglądarek. Analizuje ciąg HTML w izolowanym kontekście, usuwa niebezpieczne elementy i atrybuty (znaczniki skryptów, procedury obsługi zdarzeń, adresy URL javascript:) oraz zwraca bezpieczny ciąg HTML. Należy użyć DOMPurify.sanitize(dirtyHtml) przed przekazaniem danych do dangerouslySetInnerHTML.

Skrypty stron trzecich (analityka, widżety czatu, sieci reklamowe) działają z takimi samymi uprawnieniami jak kod JavaScript aplikacji. Przejęty lub złośliwy skrypt strony trzeciej może odczytać document.cookie, uzyskać dostęp do localStorage, odczytać dane wprowadzane do formularzy i wysyłać żądania do zewnętrznych serwerów — bez żadnego sygnału dla użytkownika.

Content Security Policy to nagłówek HTTP określający, które skrypty mogą być wykonywane. Nawet jeśli ładunek XSS zostanie wstrzyknięty do DOM, prawidłowo skonfigurowana CSP może zablokować jego wykonanie, ograniczając skrypty wbudowane i zezwalając wyłącznie na skrypty z dozwolonych źródeł. CSP stanowi drugą linię obrony po sanityzacji danych wejściowych.

Pakiety npm stanowią rzeczywisty wektor ataków XSS. Zależność może zawierać złośliwy kod, który wykrada zmienne środowiskowe lub dane użytkowników. Incydent związany z node-ipc z 2022 roku oraz przejęcie ua-parser-js z 2021 roku pokazały, że powszechnie używane pakiety mogą zostać przejęte i zatrute. Należy przeprowadzać audyt zależności za pomocą npm audit i używać plików blokad.

Udany atak XSS umożliwia atakującemu kradzież tokenu JWT użytkownika z sessionStorage (wysłanie go na serwer kontrolowany przez atakującego), wykonywanie działań jako uwierzytelniony użytkownik (wywoływanie API z użyciem jego sesji), modyfikowanie DOM w celu wyświetlania treści phishingowych lub rejestrowanie każdego naciśnięcia klawisza w aplikacji.

Przeglądarkowy interfejs API Trusted Types wymaga, aby wszystkie ujścia DOM (innerHTML, eval, script.src) otrzymywały specjalne obiekty określonego typu zamiast surowych ciągów. Zapobiega to docieraniu ładunków XSS opartych na ciągach do DOM na poziomie platformy. React zmierza do zgodności z Trusted Types, a CSP może ją wymuszać.

Bezpieczny wzorzec renderowania HTML z CMS wygląda następująco: należy pobrać HTML, przekazać go przez DOMPurify.sanitize() z listą dozwolonych bezpiecznych znaczników i atrybutów, a następnie wyrenderować za pomocą dangerouslySetInnerHTML={{ __html: cleanHtml }}. Nie wolno pomijać etapu sanityzacji, nawet jeśli ufają Państwo systemowi CMS, ponieważ sama baza danych CMS może zostać przejęta.

Co robi DOMPurify po wywołaniu DOMPurify.sanitize(htmlString)?

React automatycznie escapuje wartości JSX, zapobiegając większości ataków XSS. dangerouslySetInnerHTML omija tę ochronę na potrzeby uzasadnionego renderowania HTML — dane wejściowe należy zawsze najpierw oczyścić za pomocą DOMPurify. Skrypty stron trzecich i przejęte pakiety npm stanowią wektory ataków XSS w łańcuchu dostaw. Content Security Policy zapewnia drugą warstwę ochrony. Udany atak XSS umożliwia kradzież tokenów, podszywanie się pod użytkownika i phishing.