Podatność XSS

Question

Witam mam pytanie które dość długo mnie dręczy.

Czy da się uciec z tagu <p> i ewentualnie <b>?

Answer 1

Trochę złe pytanie zadajesz. Uciec da się z każdego tagu, jeśli jest błąd w tym jak dane są kodowane.

Comments

Dzięki za szybko odpowiedź :)

Mógłbyś mi wyjaśnić o co chodzi z tym błędem kodowania?

---

XSS jest błędem który wynika z tego, że dane (np. pochodzące od atakującego) są mieszane z sekwencjami kontrolnymi (tj. tagami HTML) w tym samym kanale komunikacji. Np.

<div id="user-id">Moja Nazwa Użytkownika</div>

Jeśli "Moją Nazwą Użytkownika" było by "<script>alert(document.domain)</script>", to – jeśli dane nie są kodowane w żaden sposób – dostajemy:

<div id="user-id"><script>alert(document.domain)</script></div>

Czyli dostajemy XSS – wykonanie kodu dostarczonego przez atakującego w przeglądarce innego zalogowanego użytkownika. Ogólnie błąd tutaj polega na wymieszaniu danych z instrukcjami sterującymi (HTML/JS), bo przeglądarka "myśli" że wszystko pochodzi z tego samego zaufanego źródła.

Jeśli natomiast w tym konkretnym przypadku zastosowalibyśmy klasyczny "escaping" (kodowanie danych), tj.:
1. zamianę & na &amp;
2. zamianę < na &lt;
3. (opcjonalnie) zamianę > na &gt;
to zamiast XSSa dostajemy po prostu:

<div id="user-id">&lt;script&t;alert(document.domain)&lt;/script&gt;</div>

co jest zupełnie nieszkodliwe.

Dodam, że innego rodzaju kodowanie/escaping używa się w różnych sytuacjach, tj:

<p>INNEGO_JAK_COS_MIEDZY_TAGAMI</p>

<div data-whatever="INNEGO_JAK_ATAKUJĄCY_KONTROLUJE_ATRYBUT">...

<style>#user-id { color: INNEGO_JAK_STYL; }</style>

<script>const username="I JESZCZE INNEGO JAK WARTOSC STRINGA W JS";</script>

Współczesne systemy szablonów mają zazwyczaj feature który się zwie "context-aware autoescaping", czyli automatyczny dobór odpowiedniego kodowania w zależności od kontekstu (miejsca) w którym wstawiana jest niezaufana wartość.

Trochę inaczej sprawa jeszcze wygląda w przypadku tzw. DOM XSS, czyli XSSa w którym wartość od atakującego nie jest wstawiana w szablonie po stronie serwera, a przez JS  po stronie przeglądarki ofiary bazując na jakiejś dynamicznie wczytanej wartości. Wtedy kwestia trochę sprowadza się do tego jakiego sposobu wstawienia danych użył programista. Np. używanie document.write czy innerHTML to zły pomysł, ale innerText, textContent czy nowe setHTML już są OK (chociaż to ostatnie pozwala na HTML injection w ograniczonym stopniu - ale i taki jest tego cel). Te dwa pierwsze sposoby są podatne na XSS, bo nie robią żadnego kodowania, etc; po prostu podsyłają dane bezpośrednio do parsera HTML. Dwa kolejne settery (innerText/textContent) natomiast wstawiają dane do samego DOM - tam już dane są rozdzielone od struktury dokumentu, więc na tym poziomie nie trzeba się martwić kodowaniem (bo wstawia się faktycznie coś o czym przeglądarka wie, że to tylko dane). To ostatnie (setHTML) wykonuje natomiast dość skomplikowany proces "sanityzacji" podanego kodu HTML, tj. jego przerobienia na taki kod, który – mimo że nadal zawiera sekwencje sterujące – nie może być wykorzystany do niczego niebezpiecznego (a przynajmniej nie do takich typowych rzeczy jak XSS).