Cross-site scripting (w skrócie XSS ) jest rodzajem lukę w zabezpieczeniach w witrynach wstrzyknąć zawartość na stronie, powodując działań na przeglądarek odwiedzających stronę. Możliwości XSS są bardzo szerokie, ponieważ atakujący może używać wszystkich języków obsługiwanych przez przeglądarkę ( JavaScript , Java ...), a nowe możliwości są regularnie odkrywane, zwłaszcza wraz z pojawieniem się nowych technologii, takich jak HTML5 . Na przykład możliwe jest przekierowanie do innej witryny w celu wyłudzenia informacji, a nawet kradzieży sesji poprzez pobranie plików cookie .
Cross-site scripting jest skracany jako XSS, aby nie mylić go z CSS (arkuszami stylów), X czytające „ krzyż ” w języku angielskim.
Termin cross-site scripting nie jest precyzyjnym opisem tego typu luki. Pionier XSS Mark Slemko powiedział:
„Problem nie dotyczy tylko skryptów i niekoniecznie coś się dzieje między wieloma witrynami. Skąd więc ta nazwa? W rzeczywistości nazwa została nadana, gdy problem był mniej zrozumiały i utknął. Uwierz mi, mieliśmy ważniejsze rzeczy do zrobienia niż wymyślenie lepszej nazwy. "
- Mark Slemko, „ Cross Site Scripting Info ” , w projekcie The Apache HTTP Server Project ,Luty 2000
Zasada jest taka, aby wprowadzić do strony internetowej dowolne dane, na przykład poprzez umieszczenie wiadomości na forum lub poprzez parametry adresu URL. Jeśli te dane dotrą w takiej postaci, w jakiej znajdują się na stronie internetowej przesłanej do przeglądarki (poprzez parametry adresu URL, opublikowaną wiadomość itp.) Bez weryfikacji, oznacza to, że istnieje wada: można je wykorzystać do wykonania złośliwego kodu za pomocą języka skryptowego ( najczęściej JavaScript ) przez przeglądarkę internetową wyświetlającą tę stronę.
Obecność błędu XSS można wykryć na przykład wpisując skrypt JavaScript w polu formularza lub w adresie URL:
<script>alert('bonjour')</script>
Jeśli pojawi się okno dialogowe, można wywnioskować, że aplikacja internetowa jest podatna na ataki XSS.
Wykorzystanie błędu typu XSS pozwoliłoby intruzowi na wykonanie następujących operacji:
Nie ma ustandaryzowanej klasyfikacji podatności na cross-site scripting, ale łatwo można wyróżnić dwa główne typy XSS: nietrwałe i trwałe. Możliwe jest również podzielenie tych dwóch typów na dwie grupy: tradycyjny XSS (spowodowany luką po stronie serwera) i oparty na DOM XSS (ze względu na lukę po stronie klienta).
Ten rodzaj naruszenia bezpieczeństwa, który można określić jako „nietrwały”, jest zdecydowanie najpowszechniejszy.
Pojawia się, gdy dane dostarczone przez klienta WWW są używane tak samo jak przez skrypty serwera do tworzenia strony wyników . Jeśli niezaznaczone dane są zawarte na stronie wyników bez kodowania jednostek HTML , można ich użyć do wstrzyknięcia kodu do strony dynamicznej otrzymanej przez przeglądarkę klienta.
Klasyczny przykład w wyszukiwarkach witryn: jeśli szukasz ciągu zawierającego specjalne znaki HTML, często wyszukiwany ciąg zostanie wyświetlony na stronie wyników, aby przypomnieć Ci o tym, czego szukano, lub w polu tekstowym w celu ponownego wydania tego kanału . Jeśli wyświetlany ciąg nie jest zakodowany, istnieje luka w zabezpieczeniach XSS.
Na pierwszy rzut oka nie jest to poważny problem, ponieważ użytkownik może tylko wstrzyknąć kod na własne strony. Jednak przy odrobinie socjotechniki osoba atakująca może przekonać użytkownika do skorzystania z oszukanego adresu URL, który wstrzykuje kod do strony wyników, dając atakującemu pełną kontrolę nad zawartością tej strony. Ponieważ inżynieria społeczna jest wymagana do wykorzystania tego typu usterki (i poprzedniej), wielu programistów uważało, że te dziury nie są zbyt ważne. Ten błąd jest często uogólniany na ogólnie luki w zabezpieczeniach XSS.
Ten rodzaj luki, zwany również luką trwałą lub luką drugiego rzędu, umożliwia potężne ataki. Występuje, gdy dane dostarczone przez użytkownika są przechowywane na serwerze (w bazie danych, plikach lub czymkolwiek), a następnie ponownie wyświetlane bez zakodowania specjalnych znaków HTML .
Klasycznym przykładem są fora, na których użytkownicy mogą publikować tekst sformatowany za pomocą tagów HTML. Luki te są większe niż w przypadku innych typów, ponieważ osoba atakująca może po prostu wstrzyknąć skrypt raz i dotrzeć do dużej liczby ofiar bez uciekania się do inżynierii społecznej.
Istnieją różne metody iniekcji, które niekoniecznie wymagają od atakującego korzystania z samej aplikacji internetowej. Wszystkie dane otrzymane przez aplikację internetową (e-mail, logi…), które mogą zostać przesłane przez atakującego, muszą zostać zakodowane przed ich prezentacją na dynamicznej stronie, w przeciwnym razie istnieje luka XSS.
Tego typu wada XSS jest znana od dawna. Artykuł napisany w 2005 roku jasno określa jego cechy. W tym scenariuszu problem tkwi w skrypcie strony po stronie klienta. Na przykład, jeśli fragment kodu JavaScript uzyskuje dostęp do parametru żądania adresu URL i używa tych informacji do zapisania kodu HTML na własnej stronie, a informacje te nie są kodowane jako encje HTML , prawdopodobnie występuje luka w zabezpieczeniach XSS. Zapisane dane zostaną ponownie zinterpretowane przez przeglądarkę jako kod HTML prawdopodobnie zawierający dodany złośliwy skrypt.
W praktyce sposób wykorzystania takiej usterki będzie podobny do następującego, z wyjątkiem bardzo ważnej sytuacji. Ze względu na sposób, w jaki program Internet Explorer traktuje skrypty po stronie klienta w obiektach znajdujących się w „strefie lokalnej” (takich jak lokalny dysk twardy klienta), luka tego typu może prowadzić do luk w zabezpieczeniach umożliwiających zdalne wykonanie. Na przykład, jeśli osoba atakująca udostępnia „złośliwą” witrynę internetową zawierającą odsyłacz do podatnej strony w systemie lokalnym klienta, może zostać wstrzyknięty skrypt, który będzie działał z uprawnieniami przeglądarki internetowej użytkownika w tym systemie. To całkowicie omija „ piaskownicę ”, a nie tylko ograniczenia międzydomenowe, które są zwykle pomijane przez XSS.
Aby uniknąć XSS, można zastosować kilka technik:
Istnieją biblioteki, które umożliwiają wydajne filtrowanie oznaczonych treści generowanych przez użytkowników (systemy publikowania).
Ponadto istnieje również możliwość ochrony przed podatnościami typu XSS przy użyciu dedykowanego sprzętu sieciowego, takiego jak zapory aplikacji. Służą one do filtrowania wszystkich przepływów HTTP w celu wykrywania podejrzanych żądań.
Kilka głównych ataków wykorzystywało luki w zabezpieczeniach skryptów między witrynami: