Podatności DOMPurify

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 (dotknięte wersje <= 3.4.5) przekazuje bezpośrednie referencje do modułowych zestawów DEFAULT_ALLOWED_TAGS i DEFAULT_ALLOWED_ATTR do hooków uponSanitizeElement i uponSanitizeAttribute przez data.allowedTags / data.allowedAttributes, gdy sanitize jest wywoływane bez jawnej tablicy cfg.ALLOWED_TAGS / cfg.ALLOWED_ATTR. Hook, który mutuje te pola, trwale rozszerza domyślne listy dozwolonych na czas życia instancji DOMPurify, więc wszystkie kolejne wywołania sanitize z domyślną konfiguracją dziedziczą rozszerzone domyślne, a ładunki atakującego używające zatrutych nazw tagów/atrybutów przetrwają sanityzację. removeAllHooks(), clearConfig() i przekazanie świeżego cfg nie przywracają stanu; tylko utworzenie nowej instancji DOMPurify.

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.