Podatności DOMPurify

DOMPurify od wersji 3.4.4 przed 3.4.17 zawiera obejście SAFE_FOR_TEMPLATES, które pozwala atakującym zachować wyrażenia szablonów w dołączonych shadow rootach podczas korzystania z trybów RETURN_DOM, RETURN_DOM_FRAGMENT lub IN_PLACE. Atakujący mogą podzielić wyrażenia na węzły tekstowe oddzielone niedozwolonymi elementami, które łączą się po usunięciu i są oceniane przez downstreamowe silniki szablonów, prowadząc do cross-site scripting.

DOMPurify w wersjach przed 3.4.17 zawiera podatność typu cross-site scripting, która pozwala atakującym zachować aktywne event handlery, gdy hook IN_PLACE usuwa węzeł nadrzędny lub sąsiedni. Znaczniki atakującego w odłączonych poddrzewach nie są przetwarzane ani neutralizowane, więc handlery takie jak img onerror uruchamiają się po zakończeniu sanitize(), powodując DOM XSS.

DOMPurify w wersjach przed 3.4.17 zawiera podatność typu cross-site scripting pozwalającą obejść zabezpieczenie SMIL attributeName=href, gdy PARSER_MEDIA_TYPE ma wartość application/xhtml+xml, ponieważ transformCaseFunc nie zamienia nazw atrybutów na małe litery. Atakujący może przesłać SVG z elementem animate lub set używającym attributeName="href" oraz wpisu javascript: w values, aby wykonać skrypt po kliknięciu przez użytkownika zsanityzowanego linku.

DOMPurify przed wersją 3.4.16 zawiera podatność na cross-site scripting, która pozwala atakującym ominąć sanityzację, ponieważ tryb IN_PLACE zwraca wymuszony usunięty element style, którego zawartość tekstowa nadal zawiera znaczniki. Atakujący mogą dostarczyć element style zawierający zamykający tag style i payload img onerror, który wykonuje skrypt, gdy aplikacja serializuje i ponownie parsuje zwrócony węzeł.

DOMPurify od wersji 3.4.13 przed 3.4.16 zawiera podatność na cross-site scripting, ponieważ tryb IN_PLACE nie neutralizuje poddrzew odłączonych przez hooki afterSanitizeElements lub afterSanitizeAttributes. Atakujący mogą dostarczyć znaczniki z handlerami on* wewnątrz wrappera usuniętego przez takie hooki, pozostawiając handlery aktywne na żywym DOM, aby wykonać skrypt w kontekście ofiary.

DOMPurify przed wersją 3.4.13 zawiera podatność na cross-site scripting w sanityzacji IN_PLACE, gdzie haki usuwania elementów nie neutralizują odłączonych poddrzew. Atakujący mogą dostarczyć HTML z handlerami zdarzeń na elementach potomnych, które wykonują się po zakończeniu sanityzacji, mimo że zwrócony korzeń wygląda na czysty.

DOMPurify przed wersją 3.4.12 nie wykonuje haka afterSanitizeElements dla elementów niestandardowych dozwolonych przez CUSTOM_ELEMENT_HANDLING.tagNameCheck, co pozwala atrybutom ominąć polityki bezpieczeństwa aplikacji. Atakujący mogą zachować wrażliwe atrybuty na elementach niestandardowych, które później ponownie wstrzykują je do zlewów innerHTML, tworząc drugorzędne gadżety XSS.

DOMPurify przed wersją 3.3.2 zawiera podatność na mutacyjne XSS, gdy oczyszczony HTML jest ponownie wstawiany do specjalnych kontekstów parsowania za pomocą innerHTML z wrapperami takimi jak script, xmp, iframe, noembed, noframes lub noscript. Atakujący mogą stworzyć ładunki z sekwencjami zamykającymi, które wychodzą poza kontekst wrappera podczas ponownego parsowania, reaktywując niebezpieczny kod z obsługą zdarzeń w celu wykonania JavaScript.

DOMPurify przed wersją 3.3.2 zawiera podatność na zatruwanie prototypu w trybie USE_PROFILES. Atakujący może ustawić właściwości prototypu Array.prototype, takie jak onclick, na true, co powoduje, że DOMPurify akceptuje procedury obsługi zdarzeń jako dozwolone atrybuty, prowadząc do XSS opartego na DOM.

DOMPurify przed wersją 3.3.2 zawiera podatność na obejście walidacji URI, gdy ADD_ATTR jest dostarczane jako funkcja predykatu przez EXTRA_ELEMENT_HANDLING.attributeCheck. Atakujący może dostarczyć predykat akceptujący określone kombinacje atrybutów i tagów, aby ominąć walidację bezpiecznych URI, umożliwiając niebezpieczne protokoły, takie jak javascript:, co prowadzi do XSS opartego na DOM.

W DOMPurify do wersji 3.3.3, funkcje predykatów dostarczone przez ADD_ATTR lub ADD_TAGS do DOMPurify.sanitize() utrzymują się w stanie wewnętrznym (EXTRA_ELEMENT_HANDLING) w kolejnych wywołaniach sanitize() na tej samej instancji. Jeśli późniejsze wywołanie dostarczy ADD_ATTR lub ADD_TAGS jako tablicę, a nie funkcję, poprzednio ustawiony handler funkcji nie jest czyszczony ani nadpisywany, co pozwala mu nadal zatwierdzać atrybuty lub tagi kontrolowane przez atakującego. Może to pozwolić na niebezpieczne atrybuty obsługi zdarzeń lub zabronione tagi (omijając FORBID_TAGS) na przetrwanie sanityzacji, prowadząc do XSS.

DOMPurify do wersji 3.3.3 nie dezynfekuje elementów DOM przekazanych w trybie IN_PLACE, gdy element pochodzi z innego okna/realm (np. contentDocument iframe). Sprawdzanie instanceof między różnymi realmami w prywatnej funkcji _isNode() zwraca false dla węzłów z obcego realm, powodując, że DOMPurify stringifikuje element (zwracając '[object HTMLDivElement]'), cicho resetuje IN_PLACE na false i zwraca niesprawdzony element z nienaruszonymi ładunkami XSS.

DOMPurify przed wersją 3.4.0 zawiera błąd logiczny w funkcji ADD_TAGS, gdzie ocena skrócona (short-circuit) pozwala zabronionym tagom ominąć ograniczenia FORBID_TAGS. Atakujący mogą stworzyć dane wejściowe zawierające tagi wymienione w FORBID_TAGS, które są również dodane przez funkcję ADD_TAGS, powodując ich zachowanie w oczyszczonym wyjściu.

DOMPurify przed wersją 3.4.7 przekazuje bezpośrednie referencje do modułowych zbiorów DEFAULT_ALLOWED_TAGS i DEFAULT_ALLOWED_ATTR do hooków uponSanitizeElement i uponSanitizeAttribute, gdy sanitize jest wywoływane bez jawnej konfiguracji. Hook modyfikujący te pola trwale rozszerza domyślne listy dozwolonych elementów dla całego czasu życia instancji DOMPurify, przez co kolejne wywołania sanitize dziedziczą rozszerzone domyślne ustawienia.

DOMPurify do wersji 3.4.6 zawiera podatność na XSS w trybie IN_PLACE, która ufa kontrolowanemu przez atakującego nodeName na żywych węzłach niebędących formularzami. Atakujący mogą dostarczyć wrogie żywe obiekty DOM z prawdziwymi dziećmi skryptów, których obserwowalny nodeName jest nadpisywany, aby wyglądać jak dozwolone elementy, powodując wykonanie skryptów po wstawieniu oczyszczonego drzewa do żywego dokumentu.

DOMPurify w wersjach od 3.0.0 do 3.4.8, skonfigurowany z SAFE_FOR_TEMPLATES i trybem wyjścia DOM, nie usuwa wyrażeń szablonów (np. ${evil}) wewnątrz elementów <template>. Ostateczne czyszczenie nie przetwarza template.content, więc wyrażenia mogą pozostać i zostać zinterpretowane przez silnik szablonów.

DOMPurify 3.0.0 przed wersją 3.4.9 nie resetuje zachowanej polityki Trusted Types po wywołaniu clearConfig(), więc instancja DOMPurify ponownie użyta w różnych granicach zaufania pozostaje związana z wcześniej dostarczoną TRUSTED_TYPES_POLICY. Późniejszy wywołujący, który żąda wyjścia RETURN_TRUSTED_TYPE, otrzymuje obiekt TrustedHTML utworzony przez starą (potencjalnie niebezpieczną) politykę, a nie czystą domyślną, co może prowadzić do wykonania skryptów w miejscu docelowym Trusted Types. Przekazanie TRUSTED_TYPES_POLICY: null w późniejszym wywołaniu również nie czyści zachowanej polityki.

DOMPurify przed wersją 3.4.11 nie klonuje listy dozwolonych atrybutów ALLOWED_ATTR podczas używania setConfig() z hookiem uponSanitizeAttribute, co pozwala hookowi na trwałą modyfikację współdzielonej listy. Atakujący mogą zarejestrować hook, który warunkowo zezwala na niebezpieczne atrybuty (np. onerror) dla zaufanych elementów, a następnie przesłać niezaufaną treść, która dziedziczy zanieczyszczoną listę i wykonuje event handlery jako przechowywany XSS.

DOMPurify przed wersją 3.4.7 zawiera podatność w trybie IN_PLACE, która pomija zawartość shadow DOM wewnątrz <template>.content. Atakujący może wstrzyknąć kod HTML z obsługą zdarzeń, URL-e JavaScript lub skrypty, które zostaną wykonane po sklonowaniu i wstawieniu oczyszczonego szablonu.

Podatność w DOMPurify przed wersją 3.4.6 pozwala zachować atrybuty obsługi zdarzeń na kontrolowanym przez atakującego formularzu <form> podczas używania DOMPurify.sanitize(root, { IN_PLACE: true }), co umożliwia ataki XSS.

DOMPurify przed wersją 3.4.6 nieprawidłowo obsługuje węzły DOM z obcych domen przy użyciu opcji IN_PLACE: true, co omija sanityzację i pozwala na przetrwanie wykonywalnego kodu.

DOMPurify w wersji 3.4.4 domyślnie zezwala na element <selectedcontent>, co pozwala przeglądarkom na ponowne sklonowanie ładunku XSS po sanityzacji. W rezultacie niesanityzowany kod wewnątrz <selectedcontent> jest zwracany. Problem został naprawiony w wersji 3.4.5.

DOMPurify w wersjach przed 3.4.0 ma niespójność między obsługą FORBID_TAGS i FORBID_ATTR, gdy używana jest funkcyjna opcja ADD_TAGS. Gdy EXTRA_ELEMENT_HANDLING.tagCheck zwraca true, sprawdzenie FORBID_TAGS jest pomijane, co pozwala zabronionym elementom przetrwać sanityzację wraz z atrybutami. Wersja 3.4.0 naprawia problem.

DOMPurify to sanitizer DOM przeznaczony do zapobiegania cross-site scripting w HTML, MathML i SVG. Od wersji 1.0.10 do wersji przed 3.4.0 opcja SAFE_FOR_TEMPLATES usuwa wyrażenia {{...}} z niezaufanego HTML, co działa w trybie tekstowym, ale nie z RETURN_DOM lub RETURN_DOM_FRAGMENT, umożliwiając XSS przez frameworki szablonów takie jak Vue 2. Wersja 3.4.0 naprawia problem.

DOMPurify to sanitizer XSS działający wyłącznie na DOM dla HTML, MathML i SVG. Wersje od 3.0.1 do 3.3.3 są podatne na obejście XSS oparte na zanieczyszczeniu prototypu: gdy aplikacja używa DOMPurify.sanitize() z domyślną konfiguracją (bez opcji CUSTOM_ELEMENT_HANDLING), wcześniejszy gadget prototype pollution może wstrzyknąć do Object.prototype permisywne wyrażenia regularne tagNameCheck i attributeNameCheck, powodując przepuszczenie przez sanityzację dowolnych elementów niestandardowych z dowolnymi atrybutami, w tym handlerami zdarzeń. Wersja 3.4.0 naprawia problem.

DOMPurify w wersjach 3.1.3 do 3.2.6 oraz 2.5.3 do 2.5.8 zawiera podatność na cross-site scripting, która pozwala atakującym ominąć sanityzację atrybutów poprzez wykorzystanie braku walidacji elementów rawtext textarea w wyrażeniu regularnym SAFE_FOR_XML. Atakujący mogą umieścić zamykające tagi rawtext, takie jak </textarea>, w wartościach atrybutów, aby wyrwać się z kontekstu rawtext i wykonać JavaScript, gdy zsanityzowany wynik zostanie umieszczony wewnątrz elementów rawtext. Gałąź 3.x została naprawiona w wersji 3.2.7; gałąź 2.x nie została nigdy załatana.