escapowanie

Escapowanie to zakodowanie danych tuż przed ich wypisaniem, tak aby odbiorca, na przykład przeglądarka albo baza danych, potraktował je jako dane, a nie jako kod lub znaczniki. Dokumentacja WordPressa definiuje escapowanie wyjścia jako zabezpieczanie danych wyjściowych przez usuwanie niechcianych elementów, takich jak zniekształcony HTML albo znaczniki skryptów ^[1]. OWASP nazywa ten zabieg kodowaniem wyjścia i podkreśla, że sposób kodowania musi odpowiadać kontekstowi, w którym dane się pojawiają ^[2]. Brak escapowania albo escapowanie błędne MITRE opisuje jako słabość CWE-116 ^[3].

Jak działa

Każdy komunikat strukturalny, na przykład strona HTML albo zapytanie SQL, łączy dane z informacjami sterującymi. MITRE wyjaśnia, że jeśli dane od atakującego trafiają do takiego komunikatu bez kodowania, znaki specjalne mogą zostać odczytane jako polecenie zamiast jako dane ^[3]. Skutkiem może być zmiana danych aplikacji, wykonanie nieuprawnionych poleceń i obejście mechanizmów ochrony ^[3].

Escapowanie zamienia znaki o znaczeniu specjalnym na ich bezpieczne odpowiedniki. W treści HTML OWASP zaleca kodowanie encjami: & na &, < na <, > na >, cudzysłów na ", apostrof na ' ^[2]. Przeglądarka wyświetli wtedy tekst znak po znaku i nie zbuduje z niego znacznika. Drogę danych od wejścia do ekranu pokazuje schemat poniżej.

RYS. 1Dane od wejścia do wyjścia

Escapowania nie należy mylić z sanityzacją danych wejściowych. Sanityzacja czyści dane przy wejściu, niezależnie od tego, gdzie trafią później. Escapowanie odbywa się na wyjściu i zależy od miejsca docelowego, dlatego jedna wartość może wymagać różnego kodowania w treści strony, w atrybucie i w adresie URL.

Konteksty wyjścia

OWASP wyróżnia kilka kontekstów, a każdy ma własne reguły ^[2].

Są też miejsca, w których kodowanie nie wystarcza: wnętrze znacznika skryptu, komentarze HTML, bloki CSS i atrybuty obsługi zdarzeń JavaScript ^[2]. OWASP zaleca w ogóle nie umieszczać tam niezaufanych zmiennych ^[2]. Gdy użytkownik ma pisać własny HTML, zamiast escapowania stosuje się oczyszczanie HTML listą dozwolonych znaczników ^[2].

W WordPressie

Rdzeń WordPressa ma osobną funkcję dla każdego kontekstu ^[1]. Najczęściej używane to esc_html() dla treści, esc_attr() dla atrybutów, esc_url() dla adresów w href i src, esc_js() dla JavaScriptu w linii, esc_textarea() i esc_xml() ^[1]. Do HTML z listą dozwolonych znaczników służą wp_kses(), wp_kses_post() i wp_kses_data() ^[1]. Warianty esc_html__(), esc_html_e(), esc_attr__() i esc_attr_e() łączą tłumaczenie z escapowaniem w jednym wywołaniu ^[1].

Dokumentacja zaleca zasadę „escape late”, czyli escapowanie w chwili wypisywania, a nie wcześniej ^[1]. Uzasadnia to łatwiejszym przeglądem kodu, brakiem ryzyka zmiany zmiennej między escapowaniem a wypisaniem oraz możliwością automatycznego skanowania ^[1].

<a href="<?php echo esc_url( $link ); ?>"
   title="<?php echo esc_attr( $tytul ); ?>">
  <?php echo esc_html( $etykieta ); ?>
</a>

W bazie danych odpowiednikiem jest $wpdb->prepare(). Dokumentacja WordPressa wymaga, by wszystkie dane w zapytaniach SQL były escapowane przed wykonaniem, i wskazuje tę metodę jako najlepszą do tego celu ^[4]. Metoda przyjmuje symbole zastępcze %s, %d, %f i %i; wartość dla %s jest escapowana i ujmowana w cudzysłów ^[5]. To podejście jest bliskie idei zapytania parametryzowanego, które MITRE wymienia jako sposób oddzielenia danych od kodu ^[3].

Zagrożenia i skutki

Brak escapowania na stronie prowadzi do XSS (Cross-Site Scripting). Dokumentacja WordPressa opisuje XSS jako wstrzyknięcie JavaScriptu do strony i zaleca unikanie go przez escapowanie wyjścia ^[4]. Najgroźniejszy jest Stored XSS, bo zapisany ładunek (payload) wykonuje się przy każdym wyświetleniu, także w panelu administratora. Brak escapowania w zapytaniu do bazy prowadzi do SQL injection ^[4].

Escapowanie niedopasowane do kontekstu jest równie groźne jak jego brak. Funkcja czyszcząca tekst dla HTML nie chroni wartości wstawianej do kodu PHP, JavaScriptu czy SQL. Dotyczy to zarówno podatności we wtyczkach, jak i podatności w motywach, bo szablony motywu także wypisują dane na stronę. Przykłady takich błędów opisuje sekcja poniżej.

Historia i przykłady

WordPress 4.8.3, listopad 2017. Sekurak opisał podatność SQL injection w rdzeniu WordPressa, poprawioną w wersji 4.8.3 ^[6]. Metoda $wpdb->prepare() działała na zasadzie wyszukaj i zamień: symbol %s był podmieniany na wartość z odpowiednim escapowaniem ^[6]. Jeśli jednak atakujący przemycił do danych sam symbol %s, a kod przekazał je do prepare() dwukrotnie, mógł sterować zapytaniem ^[6]. Wniosek artykułu: dane kontrolowane przez użytkownika nie mogą trafiać do samego szablonu zapytania ^[6].

Everest Forms Pro, lipiec 2026. Sekurak opisał podatność CVE-2026-3300 z oceną CVSS 9,8 we wtyczce Everest Forms Pro, podatne były wersje poniżej 1.9.13 ^[8]. Wtyczka przepuszczała wartości pól przez sanitize_text_field(), która nie escapuje apostrofów, a następnie przekazywała je do funkcji eval() ^[8]. Atakujący bez logowania mógł wyjść poza ciąg znaków i wykonać własny kod PHP, czyli doprowadzić do zdalnego wykonania kodu (RCE) ^[8]. Sekurak podał też, że atakujący zakładali na przejętych stronach nieautoryzowane konta administratora ^[8].

ATutor, sierpień 2026. CERT Polska 20 sierpnia 2026 roku opublikował informację o 13 podatnościach w systemie ATutor ^[7]. Jedna z nich to stored XSS w profilu użytkownika: szablon zwraca wartość pola telefonu bez odpowiedniego kodowania danych wyjściowych, więc przeglądarka ofiary wykonuje osadzony kod JavaScript ^[7]. Produkt nie ma aktywnego wsparcia i podatności nie zostały poprawione ^[7].