Cross-Site Scripting - Jak hakerzy porywają Twoją stronę

Tobias Schüring Ostatnia aktualizacja 15.01.2020
.
. 6 Min.
Cross-Site Scripting_XSS

XSS, SQL injection, XMLrpc - kiedy pojawia się aktualizacja bezpieczeństwa WordPress , raporty o aktualizacji 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 w zabezpieczeniach. Ponieważ tylko wtedy, gdy rozumiesz, jakie luki zamykają aktualizacje, możesz podjąć świadomą decyzję. Dlatego dziś przyjrzymy się cross-site scripting, czyli XSS, który jest zdecydowanie najczęstszym złożonym atakiem na strony 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 uzyskują w ten sposób poufne informacje lub dostęp do komputera poszkodowanego użytkownika. Takie ataki nie należą do rzadkości: Dobrą połowę podatności wykrytych przez dostawcę zabezpieczeń Wordfence w 2015 i 2016 roku stanowiły luki typu cross-site scripting w Plugins .. Często atak XSS stanowi następnie "bazę" dla dalszych ataków, takich jak spam, phishing czy ataki DDoS. Dlatego dziś pokażę Ci, jak dokładnie działa cross-site scripting, jakie są rodzaje ataków i jak niebezpieczne są 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.

Popularna sztuczka dla cross-site scripting: manipulowane formularze

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 zarabianie pieniędzy na swoich machinacjach. Konkretnie oznacza to, że napastnicy albo kradną dane, które następnie sprzedają, albo chcą zainfekować strony internetowe, aby włączyć je 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 oczekiwane jest wprowadzenie danych przez użytkownika (np. podczas wyszukiwania wewnątrz strony). W ramach odpowiedzi serwera złośliwy kod jest następnie wykonywany na kliencie, tj. w przeglądarce użytkownika. I właśnie w tym miejscu dochodzi do szkód, np. kradzieży danych użytkowników.

Refleksyjny cross-site scripting

Niektóre dane wejściowe, takie jak zapytania do wyszukiwarki, są odzwierciedlane przez serwer. Oznacza to, że np. po wpisaniu w pole wyszukiwania "test", strona zwróci "szukałeś 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 w Plugin WP Statistics (i załatana tego samego dnia!). Wartość wejściowa na stronie 'wps_visitors_page' była przekazywana niezaznaczona, co prowadziło do powstania luki poprzez odbity XSS. W ten sposób strona mogłaby zostać zhakowana, gdyby 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.

Działa to w następujący sposóbAtakujący rozsyła do swoich potencjalnych ofiar linki o zmanipulowanych parametrach. Nie wiedząc o tym, użytkownik klikając na link wysyła "zmanipulowane" żądanie do serwera, a złośliwy kod jest wykonywany wraz z odpowiedzią serwera. Ponieważ kod ten - w przeciwieństwie do persistent XSS - nie jest nigdzie przechowywany, haker musi go masowo dystrybuować do potencjalnych ofiar. Może to nastąpić na przykład za pośrednictwem poczty elektronicznej lub portali 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ę ataku typu cross-site scripting.
Przebieg uporczywego ataku typu cross-site scripting. Źródło: Blog SAP

Przykład: IW przypadku 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 (np. za pomocą komentarza) do zwykłego postu na forum. zwykły post na forum ze złośliwym skryptem (np. za pomocą komentarza). Użytkownicy albo otrzymują odpowiedni link do postu e-mailem, albo trafiają na odpowiedni wpis przypadkiem i wykonują skrypt, gdy wywołują post. Korzyścią dla hakera jest to, że może on teraz "szpiegować" dotkniętych klientów lub dodać ich do swojego botnetu w celu dalszych ataków.

Skrypty oparte na DOM lub lokalne skrypty cross-site

W przeciwieństwie do XSS opartego na trwałym i odbitym XSS, 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ę.

Wniosek: 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!

Jako administrator systemu Tobiasz czuwa nad naszą infrastrukturą i znajduje każdą śrubkę, aby zoptymalizować wydajność naszych serwerów. Dzięki jego niestrudzonym wysiłkom, często można go spotkać w nocy na stronie Slack .

Powiązane artykuły

Komentarze do tego artykułu

Napisz komentarz

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