Żądny wiedzy? Wbijaj na Mega Sekurak Hacking Party w maju! -30% z kodem: majearly
DOMPurify – usuń z HTML-a wszystko co zbędne (i niebezpieczne)
Wydana została nowa wersja biblioteki DOMPurify oznaczona numerem 1.0.0. Jedną z najważniejszych zmian w stosunku do poprzedniej wersji jest przeprowadzona refaktoryzacja kodu, dzięki której uzyskano zgodność ze standardem ECMAScript 2017.
Do czego służy DOMPurify i kto powinien się tą biblioteką zainteresować? Sprowadzając zagadnienie do podstaw DOMPurify służy do sanityzacji kodu HTML. Przyjmuje na wejściu dane, będące fragmentem HTML, MathML lub SVG a na wyjściu zwraca kod oczyszczony z wszelkich elementów lub atrybutów, które mogą stanowić zagrożenie. Przez zagrożenie mamy na myśli takie konstrukcje, które mogą doprowadzić do nieautoryzowanego wykonania kodu JavaScript (XSS). Biblioteką w pierwszej kolejności powinny zainteresować się osoby, które mają pod opieką projekty wymagające tolerowania danych pochodzą z niezaufanych źródeł, a które jednocześnie muszą zawierać fragmenty kodu HTML osadzanego w dalszej kolejności w drzewie DOM aplikacji. DOMPurify pomoże usunąć z danych wszystko to, co nie powinno się tam znaleźć. Biblioteka łatwo poddaje się konfiguracji, przez co możliwe jest m.in. zdefiniowanie białej listy tagów, które nie będą usuwane.
Kod biblioteki można pobrać z repozytorium GitHub a działanie w praktyce przetestować z wykorzystaniem udostępnionego demo.
Dla przejrzystości – wydana została już wersja 1.0.2 DOMPurify. Ma to związek z wprowadzonymi poprawkami, które nie mają jednak wpływu na istotę działania biblioteki.
— piochu
średnio podoba mi się robienie tego w js, w końcu najlepiej jakby oczyszczał to serwer (jeśli się to uruchamia przy wysyłaniu to żaden problem to ominąć, a jeśli przy pobieraniu danych to konieczne jest uruchomienie za każdym razem gdy dane dane są pobierane…)
Witam;ja myślę że pomysł jest bardzo dobry. Jestem za w prowadzeniem.Czy trzeba go poprawić,czy jeszcze dopracować? Wszystko co poprawia nasze bezpieczeństwo jest ważne [ bardzo ważne ] . Trudności powodują że zbyt łatwo rezygnujemy. A powinny powodować wprowadzenie usprawnień.Pozdrawiam.
Tylko, że filtrowanie na froncie nie ma większego sensu, bo:
1) wystarczy wyłączyć JSa i wysłać formularz, lub
2) grzebnąć w zapytaniu wysyłanym przez przeglądarkę do serwera.
Dosyć trywialne metody na obejście zabezpieczenia.
Jedyne miejsce gdzie ma sens korzystanie z DOMPurify’a to aplikacje wystawione z Node.JSa, gdzie może sobie on chodzić na backendzie.
Ad 1. Jak wyłączysz JS-a w przeglądarce to XSS przestaje już być Twoim problemem ;-).
Ad 2. Jeśli masz możliwość grzebania w zapytaniach/odpowiedziach, które użytkownik wysyła/dostaje z serwera, to żadna biblioteka przed XSS-em nie ochroni.
Używanie DOMPurify ma jak najbardziej sens w np. w aplikacjach typu Single Page Application, gdzie wszystkie dane wyświetlane na stronie są i tak pobierane za pomocą JS i wrzucane do drzewa DOM na zasadzie:
elem.innerHTML = dataFromServer
Zamiast tego można użyć:
elem.innerHTML = purify(dataFromServer).
To zwyczajnie proszenie się o kłopoty. Dobra praktyka jednak każe czyścić dane na wejściu a nie na wyjściu. Już nawet pomijając kwestie wydajnościowe (zwykle rzadziej zapisujesz niż wyświetlasz), to dochodzi większe ryzyko pomyłki i pominięcie sanityzacji (dane zwykle wyświetlasz w kilku miejscach, ale punktów gdzie możesz je modyfikować jest znacznie mniej) + fakt że twoja aplikacja serwuje gdzieś potencjalne niebezpieczne dane i liczy że odbiorca sam je sobie wyczyści (to może zostać wykorzystane przez inną niby niegroźną lukę w serwisie).
ECMAScript jest wstecznie kompatybilny, więc kod napisany dla ES5 automatycznie spełnia każde kolejne wersje standardu ;) nie ma tu mowy o uzyskiwaniu zgodności, a co najwyżej o wykorzystaniu nowych elementów języka.
Pozdrawiam