podatność na HTML injection

Podatność na HTML injection to możliwość wstrzyknięcia własnych znaczników przez niefiltrowane dane wejściowe.

Na czym polega wstrzyknięcie znaczników HTML

Podatność na HTML injection występuje wtedy, gdy aplikacja umieszcza dane pochodzące od użytkownika w kodzie strony bez odpowiedniego sprawdzenia i zakodowania. W takiej sytuacji osoba wpisująca treść do formularza, pola komentarza, nazwy profilu albo parametru adresu internetowego może doprowadzić do zapisania lub wyświetlenia własnych elementów HTML. Przeglądarka interpretuje wtedy część danych nie jako zwykły tekst, lecz jako strukturę dokumentu, na przykład nagłówek, odnośnik, obraz albo element formularza.

Przykładowo aplikacja oczekuje tekstu „Opis produktu”, ale zamiast wyświetlić wpisane dane dosłownie, wstawia je bezpośrednio do dokumentu za pomocą mechanizmu podobnego do innerHTML. Jeżeli dane zawierają znaczniki, mogą zmienić wygląd fragmentu strony, dodać obcy odnośnik lub utworzyć element pozornie należący do aplikacji. Sam HTML injection nie musi oznaczać wykonania kodu JavaScript. Jest jednak podatnością wynikającą z nieprawidłowego rozdzielenia danych i kodu oraz może stać się poważniejszym problemem, gdy aplikacja dopuszcza także niebezpieczne atrybuty lub błędnie filtruje zawartość.

Różnica między HTML injection a XSS

HTML injection i cross-site scripting, oznaczany skrótem XSS, są ze sobą powiązane, ale nie są dokładnie tym samym zjawiskiem. W HTML injection wstrzyknięta treść przede wszystkim wpływa na strukturę lub prezentację dokumentu. XSS oznacza możliwość doprowadzenia do wykonania niepożądanego skryptu w kontekście aplikacji. Granica między tymi kategoriami zależy od miejsca wstawienia danych, zastosowanego mechanizmu renderowania oraz skuteczności zabezpieczeń przeglądarki i aplikacji.

Nie każdy tekst zawierający nawiasy ostre jest automatycznie atakiem. Problem powstaje wtedy, gdy aplikacja traktuje kontrolowane przez użytkownika dane jako kod HTML, chociaż powinny pozostać tekstem. Zwykłe wyświetlanie danych w kontekście tekstowym wymaga kodowania znaków specjalnych, między innymi znaku mniejszości, większości, cudzysłowu i ampersandu. W HTML odpowiadają im encje takie jak <, > oraz &. Kodowanie musi być dobrane do kontekstu, ponieważ zasady bezpiecznego umieszczania danych w treści HTML, atrybucie, adresie URL i kodzie JavaScript różnią się od siebie.

Skutki błędnego renderowania danych

Najłagodniejszym skutkiem jest zmiana wyglądu strony albo jej układu. Wstrzyknięta treść może dodać duży nagłówek, zmienić formatowanie, ukryć część informacji lub wstawić odnośnik prowadzący do innej witryny. Taka modyfikacja może utrudnić korzystanie z aplikacji i wprowadzić użytkownika w błąd, szczególnie gdy obcy element wizualnie przypomina część interfejsu logowania, płatności albo ustawień konta.

Ryzyko rośnie, gdy aplikacja zezwala na niekontrolowane atrybuty, adresy zewnętrzne lub treści osadzane. Wtedy wstrzyknięty element może zostać wykorzystany do podsuwania fałszywych formularzy, przekierowania na niepożądaną stronę albo połączenia HTML injection z inną podatnością. Znaczenie ma także sposób przechowywania danych. Podatność odblaskowa pojawia się, gdy treść wraca w odpowiedzi tylko dla bieżącego żądania, natomiast podatność przechowywana występuje wtedy, gdy niebezpieczny wpis zostaje zapisany i jest później wyświetlany wielu osobom. Do oceny problemu należy odtworzyć przepływ danych od źródła wejścia przez walidację i zapis aż do końcowego miejsca renderowania.

Rozpoznanie problemu na komputerze i sposób zabezpieczenia

Podczas sprawdzania objawów warto ustalić, czy zmieniona treść pojawia się tylko w jednej aplikacji, na jednej stronie lub po użyciu konkretnego formularza. Należy porównać widok w aktualnej przeglądarce z widokiem w innym środowisku, sprawdzić kod źródłowy strony oraz narzędzia deweloperskie, zwracając uwagę na to, czy wpis użytkownika został zapisany jako tekst, czy stał się elementem drzewa DOM. Samo wyczyszczenie pamięci podręcznej przeglądarki nie usuwa podatności aplikacji, ponieważ przyczyną jest sposób obsługi danych po stronie programu.

Podstawową ochroną jest kodowanie danych przy wyświetlaniu oraz stosowanie bezpiecznych metod wstawiania tekstu, takich jak textContent zamiast innerHTML, gdy nie ma potrzeby interpretowania znaczników. Jeżeli aplikacja rzeczywiście musi przyjmować ograniczony podzbiór HTML, potrzebny jest sprawdzony sanitizer z dozwoloną listą elementów i atrybutów, a nie prosty filtr oparty na usuwaniu wybranych słów. Uzupełnieniem są walidacja danych, bezpieczne nagłówki HTTP, między innymi Content Security Policy, oraz testy obejmujące różne konteksty renderowania. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, dlatego w przypadku objawów związanych z działaniem przeglądarki lub aplikacji na takim urządzeniu można zlecić diagnostykę sprzętu i środowiska pracy.