unfiltered_html

unfiltered_html to uprawnienie (capability) WordPressa, które pozwala publikować znaczniki HTML, a nawet kod JavaScript we wpisach, stronach, komentarzach i widżetach ^[1]. Treść użytkownika z tym uprawnieniem nie przechodzi przez filtr KSES, który usuwa niedozwolone znaczniki ^[4]. Dokumentacja WordPressa ostrzega, że nadanie go niezaufanym użytkownikom może skończyć się publikacją złośliwego albo źle sformatowanego kodu ^[1]. W praktyce konto z unfiltered_html w złych rękach oznacza możliwość osadzenia XSS (Cross-Site Scripting) na stronie.

Jak działa

WordPress filtruje treść przez KSES tylko wtedy, gdy bieżący użytkownik nie ma unfiltered_html. Funkcja kses_init() najpierw zdejmuje filtry KSES, a potem dodaje je z powrotem wyłącznie użytkownikom bez tego uprawnienia ^[4]:

function kses_init() {
	kses_remove_filters();
	if ( ! current_user_can( 'unfiltered_html' ) ) {
		kses_init_filters();
	}
}

O tym, kto faktycznie ma uprawnienie, decyduje map_meta_cap(). Gdy zdefiniowana jest stała DISALLOW_UNFILTERED_HTML o wartości true, funkcja odmawia go wszystkim, także administratorom i superadministratorom ^[3]. W sieci Multisite odmawia go każdemu, kto nie jest superadministratorem ^[3]. Tę samą logikę stosuje do uprawnienia edit_css ^[3]. Kolejność sprawdzeń pokazuje schemat poniżej.

RYS. 1Czy użytkownik dostanie unfiltered_html

W WordPressie

Na pojedynczej witrynie uprawnienie mają domyślnie administrator i redaktor; w sieci Multisite wyłącznie superadministrator ^[1]. Autor, współpracownik i subskrybent go nie mają ^[1].

Zespół bezpieczeństwa WordPressa traktuje to jako cechę, a nie błąd. Podręcznik zgłaszania podatności wyjaśnia, że administratorzy i redaktorzy mogą publikować niefiltrowany HTML w tytułach, treści wpisów i komentarzach oraz wgrywać pliki HTML do biblioteki mediów ^[2]. Uzasadnia to tym, że WordPress jest narzędziem publikacyjnym, a ludzie muszą móc użyć dowolnych znaczników ^[2]. Użytkownicy o mniejszych uprawnieniach, autorzy i współpracownicy, nie mogą publikować niefiltrowanej treści ani wgrywać plików HTML ^[2]. Dlatego zgłoszenie „administrator może wstawić skrypt” nie jest traktowane jako podatność rdzenia, a testy XSS należy prowadzić z kont autora lub współpracownika ^[2].

Podatnością staje się sytuacja, w której treść od użytkownika bez unfiltered_html trafia na stronę bez filtrowania. To typowa podatność we wtyczce: pole ustawień, blok albo shortcode zapisuje HTML z pominięciem KSES. Przy wypisywaniu takich danych wtyczka powinna stosować escapowanie odpowiednie do kontekstu, np. wp_kses_post() dla HTML z listą dozwolonych znaczników ^[5].

Uprawnienia pokrewne

unfiltered_html bywa mylone z innymi uprawnieniami, które także omijają zabezpieczenia treści. Najbliższe jest unfiltered_upload, dostępne od wersji 2.3 ^[1]. Domyślnie nie ma go żadna rola, nawet superadministrator; włącza je dopiero stała ALLOW_UNFILTERED_UPLOADS w pliku konfiguracyjnym ^[1]. Po jej zdefiniowaniu na pojedynczej witrynie można je nadać każdej roli, a w sieci Multisite tylko superadministratorowi ^[1].

Drugą grupę tworzą uprawnienia edit_themes i edit_plugins, które otwierają wbudowane edytory plików motywów i wtyczek ^[1]. Dają one bezpośredni dostęp do kodu PHP, więc ich skutki są szersze niż wstawienie skryptu do treści. Opisuje je hasło edytor plików motywów i wtyczek. Wspólną cechą wszystkich trzech grup jest to, że każda z nich zamienia przejęcie konta w możliwość zmiany tego, co strona wysyła odwiedzającym.

Zagrożenia i skutki

Uprawnienie samo w sobie nie jest błędem, ale zwiększa skutki innych błędów.

• Przejęte konto redaktora. Kto przejmie konto z unfiltered_html, może osadzić skrypt wykonywany w przeglądarkach czytelników i administratorów. To Stored XSS bez żadnej podatności w kodzie. MITRE wymienia wśród skutków XSS kradzież danych sesji i ciasteczek ^[6], co prowadzi do przejęcia konta administratora.
• Rola nadana zbyt szeroko. Wtyczka do ról albo zła wartość default_role może dać uprawnienie osobom spoza zespołu redakcyjnego.
• Eskalacja przez skrypt. Skrypt uruchomiony w sesji administratora może działać w jego imieniu, na przykład utworzyć nieautoryzowane konto administratora. To klasyczna ścieżka eskalacji uprawnień.

Jak się bronić

• Stosować zasadę najmniejszych uprawnień: osobom piszącym treści przydzielać rolę autora lub współpracownika zamiast redaktora. Szerzej opisują to role i uprawnienia użytkowników.
• Jeśli nikt na stronie nie potrzebuje surowego HTML, dopisać do konfiguracji stałą, która według kodu map_meta_cap() wyłącza uprawnienie dla wszystkich ^[3]. To element utwardzania pliku wp-config.php (wp-config hardening).

// wp-config.php
define( 'DISALLOW_UNFILTERED_HTML', true );

• Pamiętać, że stała blokuje także uprawnienie edit_css ^[3]; przed włączeniem warto sprawdzić, czy motyw lub zespół z niego korzysta.
• Chronić konta z unfiltered_html silniejszym logowaniem, bo ich przejęcie daje bezpośredni kanał do wstrzyknięcia skryptu.
• Jako drugą warstwę rozważyć CSP (Content Security Policy), które ogranicza skrypty w linii także wtedy, gdy trafią do treści.
• Wtyczki przyjmujące HTML od użytkowników powinny sprawdzać current_user_can( 'unfiltered_html' ) przed zapisem i czyścić dane przez sanityzację danych wejściowych.

Historia i przykłady

Uprawnienie istnieje od WordPressa 2.0 ^[1]. Podręcznik zgłaszania podatności rdzenia wprost prosi badaczy, by testowali z kont o mniejszych uprawnieniach, bo przy nich cała treść powinna być filtrowana ^[2]. Komentarz w kodzie map_meta_cap() opisuje stałą DISALLOW_UNFILTERED_HTML jako blokadę dla wszystkich użytkowników, nawet administratorów i superadministratorów ^[3].