Cross-site scripting (XSS) to luka, która polega na wstrzyknięciu kodu po stronie klienta (JavaScript) do strony internetowej, którą przeglądają inni użytkownicy.

Luka występuje z powodu niewystarczającego filtrowania danych, które użytkownik przesyła do umieszczenia na stronie internetowej. O wiele łatwiejszy do zrozumienia konkretny przykład. Zapamiętaj dowolną księgę gości - są to programy, które mają na celu akceptację danych od użytkownika, a następnie ich wyświetlenie. Wyobraźmy sobie, że księga gości w żaden sposób nie sprawdza ani nie filtruje wprowadzonych danych, a jedynie je wyświetla.

Możesz naszkicować swój najprostszy skrypt (nie ma nic prostszego niż pisanie złych skryptów w PHP - wiele osób to robi). Ale jest już wiele gotowych opcji. Na przykład proponuję zacząć od Dojo i OWASP Mutillidae II. Jest tam podobny przykład. W samodzielnym środowisku Dojo przejdź w przeglądarce do: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Jeżeli jeden z użytkowników wpisał:

Następnie strona internetowa wyświetli:

Witam! Polub swoją witrynę.

A jeśli użytkownik wpisze w ten sposób:

Witam! Polub Twoją witrynę.

Wyświetli się tak:

Przeglądarki przechowują wiele plików cookie z dużej liczby witryn. Każda witryna może odbierać tylko pliki cookie przechowywane przez siebie. Na przykład example.com przechowuje niektóre pliki cookie w Twojej przeglądarce. Wchodzisz na inny.com, ta strona (skrypty klienta i serwera) nie może uzyskać dostępu do plików cookie przechowywanych przez example.com.

Jeśli example.com jest podatna na XSS, oznacza to, że możemy w jakiś sposób wstrzyknąć do niego kod JavaScript, a ten kod zostanie wykonany w imieniu example.com! Tych. kod ten będzie na przykład uzyskiwał dostęp do plików cookie ze strony example.com.

Chyba wszyscy pamiętają, że JavaScript jest wykonywany w przeglądarkach użytkowników, tj. w obecności XSS, osadzone złośliwy kod uzyskuje dostęp do danych użytkownika, który otworzył stronę serwisu.

Wstrzyknięty kod może zrobić wszystko to, co potrafi JavaScript, a mianowicie:

  • uzyskuje dostęp do plików cookie z witryny, którą przeglądasz
  • może wprowadzić jakiekolwiek zmiany do wygląd zewnętrzny strony
  • uzyskuje dostęp do schowka
  • potrafi wstrzykiwać programy JavaScript, takie jak keyloggery (przechwytujące naciśnięcia klawiszy)
  • podłącz się do BeEF
  • itd.

Najprostszy przykład z plikami cookie:

Faktycznie, alarm używane tylko do wykrywania XSS. Prawdziwy złośliwy ładunek wykonuje ukryte działania. Potajemnie obcuje z zdalny serwer atakującego i przekazuje mu skradzione dane.

Rodzaje XSS

Najważniejszą rzeczą do zrozumienia na temat typów XSS jest to, że są to:

  • Przechowywane (na stałe)
  • Odbite (nietrwałe)

Przykład stałych:

  • Specjalnie spreparowana wiadomość wpisana przez osobę atakującą (komentarz, post na forum, profil), która jest przechowywana na serwerze, jest pobierana z serwera za każdym razem, gdy użytkownicy żądają wyświetlenia strony.
  • Atakujący uzyskał dostęp do danych serwera, na przykład poprzez: Wstrzyknięcie SQL i wstrzyknął złośliwy kod JavaScript (za pomocą keyloggerów lub BeEF) do danych przekazywanych użytkownikowi.

Przykład nietrwały:

  • W witrynie jest wyszukiwanie, które wraz z wynikami wyszukiwania pokazuje coś w rodzaju „Wyszukiwałeś: [ciąg wyszukiwania]”, podczas gdy dane nie są poprawnie filtrowane. Ponieważ taka strona jest wyświetlana tylko tym, którzy mają do niej link, dopóki atakujący nie wyśle ​​linku do innych użytkowników witryny, atak nie zadziała. Zamiast wysyłać link do ofiary, można użyć hostingu złośliwego skryptu na neutralnej stronie odwiedzanej przez ofiarę.

Rozróżniają także (niektórzy jako rodzaj nietrwałych podatności XSS, niektórzy twierdzą, że ten typ może być również typem trwałego XSS):

  • Modele DOM

Funkcje XSS opartego na DOM

Mówiąc prościej, możemy zobaczyć złośliwy kod „normalnego” nietrwałego XSS, jeśli otworzymy kod HTML. Na przykład link jest tworzony w ten sposób:

http://example.com/search.php?q="/>

A kiedy otwieramy źródłowy kod HTML, widzimy coś takiego: