Bezpieczeństwo aplikacji webowych - luka XSS

Scenariusz ataku

1. Atakujący lokalizuje lukę XSS na stronie internetowej używanej przez ofiarę, np. na stronie banku
2. Ofiara jest obecnie zalogowana na tej stronie
3. Atakujący wysyła ofierze spreparowany adres URL
4. Ofiara klika adres URL
5. Na ofierze bank strona internetowa, JavaScript kod rozpoczyna wykonywanie w celu przechwycenia danych użytkownika lub wykonania przelewu w jego imieniu na konto atakującego

Warto zauważyć, że operacje wykonywane w imieniu ofiary mogą być dla niej niewidoczne, gdyż mogą odbywać się w tle z wykorzystaniem API banku lub atakujący może wykonać je później z wykorzystaniem danych potrzebnych do uwierzytelnienia, tokenów, ciasteczek itp.

Typy XSS

1. Odbity XSS

Jest to taki, w którym kod HTML/JavaScript zawarty w dowolnym parametrze (np. GET, POST lub cookie) jest wyświetlany w odpowiedzi.

Strona z wejściem tekstowym do wyszukiwania czegoś, co umieszcza parametr search=foo w końcówce adresu URL podczas odpytywania API. Po wpisaniu dowolnej frazy, jeśli nie zostanie ona odnaleziona, zostanie wyświetlony komunikat zwrotny w formacie HTML.

<div>Nie znaleziono wyników dla <b>foo</b></div>

Możemy spróbować wpisać adres URL search=...

2.DOM XSS

Dzieje się tak, gdy jego wykonanie jest włączone przez użycie niebezpiecznych funkcji w JavaScript, takich jak `eval` lub `innerHtml`. Poniższy "Przykład na żywo" pokazuje atak DOM XSS oparty na funkcji `innerHtml` funkcja.

3. Przechowywane XSS

Jest to sytuacja, w której złośliwy kod zostaje napisany po stronie serwera. Na przykład, możemy wysłać komentarz ze złośliwym kodem do wpisu na blogu, który jest przesyłany na serwer. Jego zadaniem jest na przykład oczekiwanie na moderację administratora, a następnie kradzież jego danych sesji itp.

Metody wtrysku

1. W treści znacznika

`onerror=alert('XSS')`do

<img src onerror="alert('XSS')" />

2. W treści atrybutu

`" onmouseover=alert('XSS')` do

<div class="" onmouseover="alert('XSS')""></div>

3. W treści atrybutu bez cudzysłowów

x onclick=alert('XSS')do

<div class="x" onclick="alert('XSS')"></div>

4. W hrefatrybut ef

javascript:alert('XSS') do

<a href="javascript:alert('XSS')"></a>

5. W ciągu wewnątrz kodu JavaScript

";alert('XSS')//. do

.

6. W atrybucie ze zdarzeniem JavaScript

');alert('XSS')//. gdzie ' jest pojedynczym cudzysłowem, w

<div onclick="change('&#39;);alert('XSS')//')">John</div>

7. W href atrybut wewnątrz protokołu JavaScript

);alert(1)//. gdzie %27 jest pojedynczym cudzysłowem, w

<a href="javascript:change('');alert(1)//')">kliknięcie</a>




Przykład na żywo

Metody obrony

1. Kodowanie danych przy użyciu wbudowanych funkcji dostępnych w wielu aplikacjach języki programowania.
2. Korzystanie z systemów szablonów z automatycznym kodowaniem. Większość popularnych frameworków korzystających z takich systemów chroni nas przed XSS injection (Django, Templates, Vue, React itp.).
3. Nie używaj funkcji takich jak eval lub Funkcja z niezaufanymi danymi użytkownika.
4. Nie używaj funkcji i właściwości, które przypisują kod HTML bezpośrednio do elementów drzewa DOM, np, innerHTML, outerHTML, insertAdjacentHTML, ocument.write. Zamiast tego można użyć funkcji, które przypisują tekst bezpośrednio do tych elementów, takich jak textContent lub innerText.
5. Zachowaj ostrożność, przekierowując użytkownika na adres URL, który jest pod jego kontrolą. Ryzyko wstrzyknięcia location = 'javascript('XSS')'.
6. Filtrowanie HTML przy użyciu bibliotek takich jak DOMPurify.
7. Zachowaj ostrożność podczas przesyłania .html lub .svg files. Można utworzyć oddzielną domenę, z której będą obsługiwane przesłane pliki.
8. Użyj Content-Security-Policy mechanizm.
9. Spójrz na filtry anty-XSS wbudowane w większość popularnych przeglądarek.

   Jeśli uważasz ten artykuł za interesujący, śledź Łukasza na Githubie: https://github.com/twistezo

Czytaj więcej:

Strategie pobierania danych w NextJS

Rails API i CORS. Szczypta świadomości

Dlaczego (prawdopodobnie) powinieneś używać Typescript?