Cross Site Scripting

Cross Site Scripting - jak można porwać Twoją stronę internetową

XSS, SQL Injection, XMLrpc - kiedy pojawia się aktualizacja bezpieczeństwa WordPressa, updatereports zawierają głównie kryptyczne akronimy. Nawet jeśli jest jasne, że te aktualizacje są konieczne, a wzrost bezpieczeństwa jest bardzo przyjemny, ważne jest, aby zrozumieć, co kryje się za tymi lukami bezpieczeństwa. Ponieważ tylko wtedy, gdy rozumiesz, jakie luki likwidują aktualizacje, możesz podjąć świadomą decyzję. Dlatego dziś zajmiemy się Cross Site Scripting, czyli XSS, który jest zdecydowanie najczęstszym złożonym atakiem na strony internetowe WordPressa.

Ataki hakerów można porównać do włamania. Ataki Brute Force są bardziej podobne do metody łomu. Przestępcy opierają się o narzędzie, dopóki nie otworzą drzwi lub okna. Z drugiej strony, ataki na luki XSS są wyrafinowane: Przestępcy wiedzą dokładnie, od czego zacząć i uzyskują ukierunkowany dostęp do strony internetowej.

W przypadku cross-site scripting luki w zabezpieczeniach stron internetowych są celowo wykorzystywane. Złośliwe skrypty są wprowadzane do godnego zaufania kontekstu (Twojej strony internetowej!). Podobnie jak pasażer na gapę na statku, złośliwy kod wykorzystuje Twoją stronę jako narzędzie do realizacji własnych celów.

W najgorszym przypadku dochodzi do zdobycia poufnych informacji, a nawet dostępu do komputera poszkodowanego użytkownika. Takie ataki nie należą do rzadkości: Ponad połowa luk w zabezpieczeniach wtyczek znalezionych przez dostawcę zabezpieczeń Wordfence w 2015 i 2016 roku to luki typu cross-site scripting. Atak XSS często stanowi "podstawę" dla dalszych ataków, takich jak spam, phishing czy ataki DDoS. Dlatego pokażę Ci dzisiaj, jak dokładnie działa Cross Site Scripting, jakie są rodzaje ataków i jak bardzo są one niebezpieczne.

Cross Site Scripting ma podstawową zasadę

Cross-site scripting działa na zasadzie wykorzystania luki i wstrzyknięcia złośliwego kodu na stronę internetową. Zawsze istnieje niebezpieczeństwo, gdy aplikacja internetowa przekazuje wprowadzone dane do przeglądarki bez sprawdzenia, czy nie zawiera ona ewentualnego kodu skryptu. Dobrym przykładem takiej aplikacji jest czat.

Złośliwe skrypty mogą dotrzeć do serwera przez samą aplikację internetową. Stamtąd złośliwy kod prędzej czy później trafia do zaatakowanych klientów. Dobrym przykładem takiej luki XSS jest błąd w metaopisach obrazów w WooCommerce 2.6.2. Z powodu błędu możliwe było przeniknięcie kodu HTML do metaopisów obrazów z zewnątrz. Każde urządzenie, na którym zaatakowany obraz był teraz dokładniej oglądany (np. poprzez kliknięcie na obraz), ryzykowało atakiem. W ten sposób między innymi komputery, na których oglądano ten obraz, mogły zostać zainfekowane wirusem.

"*" wyświetla wymagane pola

Chcę otrzymywać newsletter, aby być informowanym o nowych artykułach na blogu, e-bookach, funkcjach i nowościach dotyczących WordPress. Mogę wycofać swoją zgodę w dowolnym momencie. Należy zapoznać się z naszą Polityką prywatności.
To pole służy do weryfikacji i nie powinno być zmieniane.

Popularne sztuczki związane ze skryptami cross-site: manipulowanie formularzami

XSS może również umożliwić zastąpienie nieszkodliwych formularzy zmanipulowanymi formularzami. Formularze te następnie zbierają dane ofiar (na Twojej stronie!). Nawiasem mówiąc, nawet szyfrowanie SSL nie może przed tym ochronić. HTTPS oznacza, że połączenie między serwerem a klientem jest szyfrowane. Jeśli jednak sam formularz został zmanipulowany, nawet szyfrowane połączenie jest bezużyteczne.

Podobnie jak w przypadku innych rodzajów ataków, celem w większości przypadków jest monetyzacja. Konkretnie oznacza to, że albo dane są wykradane, a następnie sprzedawane, albo zainfekowane strony internetowe są włączane do tzw. botnetu, który jest następnie wynajmowany.

3 typy XSS

Ataki typu cross-site scripting można z grubsza podzielić na trzy rodzaje:

  • Odbity skrypt cross site
  • Trwały cross site scripting
  • DOM lub lokalny cross site scripting

Z grubsza rzecz biorąc, ataki XSS działają w następujący sposób: Złośliwy kod jest wstrzykiwany w miejscu, gdzie oczekuje się danych wejściowych od klienta (na przykład podczas wyszukiwania na stronie). W ramach odpowiedzi serwera złośliwy kod jest następnie wykonywany na kliencie, czyli w przeglądarce. I to właśnie tam wyrządzane są odpowiednie szkody, na przykład wykradane są dane.

Odbijanie skryptów krzyżowych

Niektóre dane wejściowe, takie jak zapytania do wyszukiwarki, są odzwierciedlane przez serwer. Oznacza to, że na przykład po wpisaniu w polu wyszukiwania słowa "test" strona wypisuje komunikat " Szukałeś testu". Wprowadzony tekst staje się więc częścią odpowiedzi serwera.

Właśnie to jest umiejętnie wykorzystywane: Jeśli zamiast wyszukiwanego hasła na serwer WWW zostanie wysłany złośliwy skrypt, można tak zmanipulować stronę, że w końcu go wykona. Ten typ ataku nazywany jest również nietrwałym (non-persistent). Oznacza to, że złośliwy kod jest tylko tymczasowo wstrzykiwany na daną stronę internetową, ale nie jest przechowywany.

W lipcu 2017 roku taka luka została znaleziona we wtyczce WP Statistics (i już naprawiona tego samego dnia!). Wartość wejściowa na stronie 'wps_visitors_page' była przekazywana bez zaznaczenia, co powodowało lukę poprzez odbity XSS. Jeśli administrator kliknął wcześniej na odpowiednio zmanipulowany link, można było włamać się na stronę.

Cross Site Scripting Reflected XSS
Tak może wyglądać odbity atak typu cross-site scripting.

Tak to działa: Linki ze zmanipulowanymi parametrami są rozsyłane do potencjalnych ofiar. Nie wiedząc o tym, ofiara wysyła "zmanipulowane" żądanie do serwera, klikając na link, a złośliwy kod zostaje wykonany wraz z odpowiedzią serwera. Ponieważ kod - w przeciwieństwie do trwałego XSS - nie jest nigdzie przechowywany, musi być masowo rozprowadzany wśród potencjalnych ofiar. Może to nastąpić na przykład za pośrednictwem poczty elektronicznej lub sieci społecznościowych.

Trwały cross site scripting

W przypadku trwałego XSS złośliwe skrypty są przechowywane na serwerze internetowym i dostarczane za każdym razem, gdy są wywoływane przez klienta. Najbardziej narażone na to są aplikacje internetowe, które przechowują dane użytkownika na serwerze, a następnie wysyłają je bez sprawdzania i kodowania (w tym fora). Ten rodzaj skryptów może być szczególnie niebezpieczny dla często odwiedzanych blogów i forów, ponieważ złośliwe oprogramowanie może się tam szybko rozprzestrzeniać ze względu na dużą liczbę użytkowników.

Ta grafika pokazuje możliwą sekwencję trwałego ataku typu cross-site scripting.
Sekwencja trwałego ataku typu cross-site scripting. Źródło: Blog SAP

Przykład: Na forum wypowiedzi są przechowywane w bazie danych. Nierzadko są one przechowywane w sposób niezaznaczony i niezaszyfrowany. Ta możliwość jest łatwo wykorzystywana i pozwala na dodanie złośliwego skryptu do zupełnie normalnego postu na forum (w prosty sposób za pomocą komentarza). Użytkownicy albo otrzymują odpowiedni link do postu pocztą elektroniczną, albo przypadkowo trafiają na odpowiedni wpis i wykonują skrypt, kiedy wywołują post. Teraz na przykład zaatakowani klienci mogą być "szpiegowani" lub dodani do botnetu w celu przeprowadzenia dalszych ataków.

Skrypty oparte na DOM lub lokalne skrypty cross-site

W przeciwieństwie do trwałego i odbitego XSS, cross site scripting oparty na DOM (Document Object Model) działa poprzez wykonywanie skryptów po stronie klienta. Oznacza to, że serwer nie jest świadomy takiego ataku, a środki bezpieczeństwa po stronie serwera również nie pomagają.

Znanym przykładem takiej luki jest przypadek pakietu genericon. Pakiet genericon to zestaw ikon używany przez wiele wtyczek. Możliwe było wstrzyknięcie złośliwego kodu poprzez plik HTML znajdujący się w tym zestawie ikon.

Po wpisaniu tego adresu URL pojawił się alert javascript. Jest to dowód na to, że wprowadzony kod javascript może być użyty do manipulowania daną stroną.
Po wpisaniu tego adresu URL pojawił się alert JavaScript. Jest to dowód na to, że wprowadzony kod JavaScript mógł zostać użyty do manipulowania daną stroną internetową. Źródło: securityaffairs.co

Warunkiem koniecznym do przeprowadzenia ataku XSS opartego na DOM jest jednak kliknięcie przez użytkownika zmanipulowanego adresu URL. Wywołując ten adres, złośliwy kod może zostać wykonany przez lukę w skrypcie po stronie klienta. Między innymi fakt, że najpierw trzeba kliknąć odnośnik, sprawia, że XSS oparty na DOM jest nieco trudniejszym, a przez to mniej prawdopodobnym rodzajem ataku.

Cross Site Scripting Local XSS
Przykład lokalnego ataku typu cross-site scripting.

Przykład: Zmanipulowany adres URL zostaje kliknięty i wysyła żądanie do aplikacji internetowej. Aplikacja odpowiada przekazując kod skryptu (który jest błędny, ale nie zmanipulowany) do przeglądarki, aby rozpocząć wykonywanie skryptu. Zmanipulowane parametry z adresu URL są teraz interpretowane w przeglądarce klienta jako część skryptu i wykonywane. W ten sposób strona wyświetlana w przeglądarce zostaje zmieniona, a użytkownicy widzą zmanipulowaną stronę, nie zauważając tego.

Środki przeciwko Cross Site Scripting

Najlepsze środki przeciwko atakom cross-site scripting są proste do wdrożenia. Najlepiej jest polegać na regularnych aktualizacjach, zaporach ogniowych i białych listach. Po drugie, można również zabezpieczyć dane wyjściowe serwera.

Regularne aktualizacje

Luki, przez które infiltrowany jest złośliwy kod, znajdują się w rdzeniu WordPressa, we wtyczkach lub w motywach. Właśnie dlatego regularne aktualizacje wszystkich tych komponentów są tak ważne. Ponieważ luki, które zostały znalezione do tej pory, są naprawiane w tych aktualizacjach.

Warto również regularnie czytać szczegóły aktualizacji, aby dowiedzieć się, które luki w zabezpieczeniach są regularnie usuwane za pomocą aktualizacji. Na przykład w przypadku konserwacji i aktualizacji zabezpieczeń rdzenia WordPress informacje te są udokumentowane na blogu WordPress.

Zapory ogniowe i białe listy chroniące przed prostymi atakami XSS

Innym prostym środkiem ochronnym przed atakami XSS są tak zwane zapory aplikacji internetowych (WAF). Zapory te są sercem dużych wtyczek bezpieczeństwa i są zasilane najnowszymi lukami w zabezpieczeniach przez odpowiedni zespół badawczy producenta. WAF to zazwyczaj procedura, która chroni aplikacje internetowe przed atakami za pośrednictwem protokołu HTTP (Hypertext Transfer Protocol).

Jednak nawet te mechanizmy ochronne mają swoje ograniczenia. W przypadku niektórych ataków XSS atak odbywa się za pośrednictwem bazy danych. Dlatego sprawdzanie danych wprowadzanych przez użytkownika pod kątem złośliwego kodu jest jednym z głównych mechanizmów bezpieczeństwa w walce z atakami XSS. Na przykład treść komentarzy jest skanowana pod kątem podejrzanych ciągów znaków i w razie potrzeby sortowana.

Wyjście danych powinno być również zabezpieczone

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <> und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Do jej wdrożenia potrzebne są umiejętności programistyczne. Ta ochrona danych wyjściowych jest łatwa do wdrożenia dla kogoś z taką wiedzą.

Zdrowy sceptycyzm: Jak chronią się użytkownicy

Ale nie tylko sama strona internetowa, ale także klienci (tj. Twoja przeglądarka internetowa) są narażeni na ataki XSS. Wielu atakom XSS można zapobiec poprzez krytyczne i ostrożne obchodzenie się z "obcymi" linkami. Istnieje między innymi możliwość korzystania z dodatków NoScript. Zapobiegają one wykonywaniu skryptów, tj. szkodliwych linii kodu, które między innymi kradną dane.

Ci, którzy chcą być po bezpiecznej stronie, mogą również uniknąć skryptów cross-site po stronie klienta, po prostu wyłączając obsługę JavaScript w przeglądarce. Ponieważ jeśli tak zwane aktywne skrypty są wyłączone, niektóre rodzaje ataków XSS nie mają już szans, ponieważ szkodliwe aplikacje nie są nawet uruchamiane. Jednak większość nowoczesnych stron internetowych nie "działa" już prawidłowo - lub w najgorszym przypadku nie działa wcale. Dlatego konieczne jest rozważenie aspektów bezpieczeństwa i użyteczności. Jeśli jesteś zainteresowany tą opcją, możesz ją znaleźć w ustawieniach przeglądarki.

Wnioski

Luki XSS to jedne z najczęstszych furtek dla złośliwego kodu. Często taki atak stanowi podstawę do dalszych ataków, takich jak spam, phishing czy ataki DDoS. Twoja strona internetowa zostaje przejęta i wykorzystana do innych celów. XSS nie jest więc pozbawione niebezpieczeństwa, dlatego tak ważna jest odpowiednia ochrona.

Refleksyjne i trwałe XSS są szczególnie powszechne, ponieważ lokalne cross-site scripting jest bardziej skomplikowane i trudniejsze do wdrożenia. Szczególnie zagrożone są strony internetowe, które przekazują wprowadzone dane użytkownika do przeglądarki bez sprawdzenia, czy nie zawiera ona złośliwego kodu. Znalezienie takich luk nie jest jednak takie proste. W zasadzie jest to właśnie zadanie dla dostawców zabezpieczeń, takich jak sucuri i inni, którzy stale rozwijają swoje środki bezpieczeństwa.

Ale oczywiście istnieje również sposób, aby zwykły WordPress chronił się przed tymi atakami. Aktualizacje wszystkich komponentów WordPressa są między innymi prostym, ale bardzo skutecznym środkiem. Jeśli aktualizujesz swoje wtyczki i motywy oraz korzystasz z WAF, zrobiłeś już duży krok we właściwym kierunku. Jeśli korzystasz również z białych list dla kodu przychodzącego i wychodzącego, to już doskonale zabezpieczyłeś swoją witrynę. Jednak szczególnie dwa ostatnie środki nie są łatwe do wdrożenia bez wiedzy programistycznej.

W porównaniu do dość prymitywnych ataków brute force, bardziej złożone ataki XSS są niestety nadal stosunkowo często skuteczne. Jednak tych tak zwanych złożonych ataków jest znacznie mniej niż ataków brute force na strony WordPress. Niemniej jednak, powinieneś maksymalnie utrudnić te ataki. Udany hack nie tylko kosztuje czas i pieniądze na usunięcie skryptów, ale może również zagrozić Twojej pozycji w wyszukiwarkach.

Spodobał Ci się ten artykuł?

Zostawiając opinię pomożesz nam udoskonalać publikowane przez nas treści.

Napisz komentarz

Twój adres e-mail nie zostanie opublikowany. Pola wymagane oznaczone są *.