Cross-Site Scripting_XSS

Cross-site scripting - Jak hakerzy przejmują Twoją witrynę

XSS, SQL injection, XMLrpc - kiedy pojawia się aktualizacja zabezpieczeń WordPress, updatereports zawierają głównie kryptyczne akronimy. Nawet jeśli wiadomo, że te aktualizacje są konieczne, a wzrost bezpieczeństwa jest bardzo przyjemny, ważne jest, aby zrozumieć, co kryje się za tymi lukami w zabezpieczeniach. Ponieważ tylko wtedy, gdy rozumiesz, jakie luki wypełniają aktualizacje, możesz podjąć świadomą decyzję. Dlatego dziś zajmiemy się cross-site scriptingiem, czyli XSS, zdecydowanie najczęstszym złożonym atakiem na witryny WordPress.

Ataki hakerów można porównać do włamywaczy. Brute Force Ataki są bardziej podobne do metody łomu. Przestępca stawia opór narzędziu, dopóki drzwi lub okno nie zostaną otwarte. Z drugiej strony, ataki na luki XSS są wyrafinowane: Włamywacz wie dokładnie, od czego zacząć i uzyskuje ukierunkowany dostęp do strony.

W trakcie cross-site scripting, luki w zabezpieczeniach stron internetowych są celowo wykorzystywane. Hakerzy wstrzykują złośliwe skrypty w zaufany kontekst (Twoje strony!). Podobnie jak pasażer na gapę na statku, ten złośliwy kod wykorzystuje Twoją stronę jako narzędzie do realizacji własnych celów.

W najgorszym przypadku napastnicy mogą w ten sposób uzyskać poufne informacje lub dostęp do komputera uszkodzonego 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. Często atak XSS stanowi podstawę do dalszych ataków, takich jak spam, phishing czy ataki DDoS. Dlatego dziś pokażę Ci jak dokładnie działa cross-site scripting, jakie rodzaje ataków istnieją i jak niebezpieczne są te ataki.

Cross-site scripting zawsze działa w podobny sposób: złośliwy kod dostaje się na Twoją stronę przez lukę

Cross-site scripting jest zagrożeniem, gdy aplikacja internetowa przekazuje wprowadzone przez użytkownika dane do przeglądarki internetowej bez sprawdzenia, czy nie zawiera ona kodu skryptu. Dobrym przykładem takiej aplikacji internetowej jest czat wsparcia.

Przez samą aplikację internetową złośliwe skrypty mogą dostać się na serwer. Stamtąd złośliwy kod prędzej czy później trafia do zainfekowanych klientów. Dobrym przykładem takiej luki XSS jest odkryty w lipcu 2016 roku błąd w meta-infosach obrazków w WooCommerce 2.6.2. Błąd umożliwiał atakującym wstrzykiwanie kodu HTML do meta opisów obrazów z zewnątrz. Każdy klient, który przyjrzałby się bliżej danemu obrazkowi (np. klikając na niego), byłby narażony na atak. Na przykład haker mógł zainfekować wirusem komputery Twoich klientów.

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

XSS może również pozwolić hakerom na zastąpienie nieszkodliwych formularzy zmanipulowanymi. Formularze te następnie zbierają dane ofiar (odwiedzających Twoją stronę!). DPrzy okazji, nawet szyfrowanie SSL nie jest w stanie Cię przed tym uchronić. HTTPS "only" 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 hakerów jest najczęściej monetyzacja ich działań. Konkretnie oznacza to, że atakujący albo kradną dane, które następnie sprzedają, albo chcą zainfekować strony internetowe w celu włączenia ich do tzw. botnetu, który następnie jest wynajmowany.

3 typy XSS: reflected, persistent i local XSS

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

Z grubsza rzecz biorąc, ataki XSS działają w następujący sposób: Złośliwy kod jest wstrzykiwany tam, gdzie oczekuje się danych wejściowych od użytkownika (np. w wyszukiwaniu wewnątrz strony). W ramach odpowiedzi serwera złośliwy kod jest następnie wykonywany na kliencie, czyli w przeglądarce użytkownika. I właśnie w tym miejscu dochodzi do szkód, np. kradzieży danych użytkowników.

Odbijanie skryptów cross-site

Niektóre dane wejściowe, takie jak zapytania do wyszukiwarki, są odzwierciedlane przez serwer. Oznacza to na przykład, że po wpisaniu w pole wyszukiwania słowa „test” na stronie pojawi się komunikat "Szukano testu". Tak więc to, co wpisuje użytkownik, staje się częścią odpowiedzi serwera.

Właśnie to sprytnie wykorzystują napastnicy: Jeśli zamiast wyszukiwanego hasła do serwera WWW zostanie wysłany złośliwy skrypt, strona może zostać zmanipulowana w celu jego ostatecznego wykonania. Ten typ ataku jest również znany jako nietrwały określane jako non-persistent. Złośliwy kod jest więc tylko tymczasowo wstrzykiwany na daną stronę, ale nie jest przechowywany.

W lipcu taka luka została znaleziona we wtyczce WP Statistics (i już naprawiona tego samego dnia!). Wartość wejściowa na stronie 'wps_visitors_page' została przekazana bez zaznaczenia, co doprowadziło do powstania luki poprzez odbity XSS. W ten sposób można było włamać się na stronę, jeśli administrator wcześniej kliknął na odpowiednio zmanipulowany link

Na przykład, odbity atak typu cross-site scripting może wyglądać tak.
Na przykład, odbity atak typu cross-site scripting może wyglądać tak.

Tak to działa: Atakujący rozsyła do swoich potencjalnych ofiar linki o zmanipulowanych parametrach. Nie wiedząc o tym, użytkownik wysyła do serwera "zmanipulowane" żądanie, klikając na link, a złośliwy kod zostaje wykonany wraz z odpowiedzią serwera. Ponieważ kod - inaczej niż w przypadku trwałego XSS - nie jest nigdzie przechowywany, haker musi go masowo rozprowadzać wśród potencjalnych ofiar. Może się to zdarzyć 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 WWW i dostarczane za każdym razem, gdy są wywoływane przez klienta. Predestynowane do tego są aplikacje internetowe, które przechowują dane użytkownika na serwerze, a następnie wypuszczają je bez weryfikacji i kodowania (np. fora). Ten rodzaj skryptów może być szczególnie niebezpieczny dla często odwiedzanych blogów i forów, ponieważ tutaj złośliwe oprogramowanie może się szybko rozprzestrzeniać ze względu na dużą liczbę użytkowników.

Ta grafika pokazuje możliwą sekwencję trwałego ataku typu cross-site scripting.
Przebieg uporczywego 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. Atakujący wykorzystują tę okazję i dodają złośliwy skrypt do zwykłego posta na forum (np. za pomocą komentarza). Użytkownicy otrzymują odpowiednie łącze do postu pocztą elektroniczną lub trafiają na odpowiedni wpis przypadkowo i wykonują skrypt, kiedy wywołują post. Korzyść dla hakera: może teraz "szpiegować" zaatakowanych klientów lub dodać ich do swojego botnetu w celu przeprowadzenia kolejnych 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 podatności jest przypadek pakietu genericon. Pakiet genericon jest zestawem ikon, który jest używany przez wiele stron Plugins, w tym Jetpack. Możliwe było wstrzyknięcie złośliwego kodu poprzez plik HTML 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ą. Źródło: securityaffairs.co

Jednak warunkiem koniecznym do przeprowadzenia ataku XSS opartego na DOM jest kliknięcie przez użytkownika na zmanipulowany adres URL. Wywołując ten adres URL, złośliwy kod może zostać wykonany poprzez lukę w skrypcie po stronie klienta. Między innymi fakt, że link musi być najpierw kliknięty, sprawia, że XSS oparty na DOM jest nieco trudniejszym, a przez to mniej prawdopodobnym rodzajem ataku.

Grafika przedstawia możliwą sekwencję lokalnego ataku typu cross-site scripting.
Przykład lokalnego ataku typu cross-site scripting. Źródło: heise.de

Przykład: Użytkownik klika na zmanipulowany adres URL i wysyła żądanie do aplikacji internetowej. Aplikacja internetowa odpowiada przekazując kod skryptu (który jest nieprawidłowy, ale nie manipulowany) do przeglądarki, aby rozpocząć wykonywanie skryptu. Zmanipulowane parametry z adresu URL są teraz interpretowane i wykonywane w przeglądarce użytkownika jako część skryptu. Strona wyświetlana w przeglądarce zostaje w ten sposób zmieniona, a użytkownik widzi teraz - nie zauważając tego - zmanipulowaną stronę.

Podsumowanie: Dość częste i nie pozbawione niebezpieczeństwa, dlatego ważna jest odpowiednia ochrona.

Luki XSS są jedną z najczęstszych furtek dla złośliwego kodu. Często atak ten stanowi podstawę do dalszych ataków, takich jak spam, phishing czy ataki DDoS. Atakujący porywają Twoją stronę i wykorzystują ją do osiągnięcia własnych celów.

Odbite i uporczywe XSS są szczególnie powszechne, ponieważ lokalne cross-site scripting są bardziej skomplikowane i trudniejsze do zaimplementowania. Strony, które szczególnie narażone są te, które przesyłają dane użytkownika do przeglądarki internetowej bez sprawdzenia, czy nie zawierają 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 and Co, którzy stale rozwijają swoje środki bezpieczeństwa.

Ale oczywiście istnieje również sposób, w jaki zwykli użytkownicy WordPress mogą chronić się przed tymi atakami. Prostym, ale bardzo skutecznym środkiem są na przykład aktualizacje wszystkich komponentów WordPress . Jak Ty, jako operator strony, ale także jako użytkownik Internetu, możesz zapobiec cross-site scriptingowi, wyjaśnimy w naszym kolejnym artykule na ten temat.

Masz jeszcze jakieś uwagi lub pytania? A potem po prostu zostaw komentarz!

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ą *.