Wprowadzenie
Jesteś programistą, który otrzymał zadanie naprawienia błędu typu XSS – czyli cross site scripting.
Teoretycznie wiesz, że jest to możliwość wykonania zewnętrznego kodu JS w obrębie danej domeny.
Z drugiej jednak strony, nie do końca rozumiesz pośpiech i konieczność ich naprawiania.
Przecież samemu tworzysz kod na co dzień, więc co złego może się stać.
A może jesteś prezesem firmy bądź osobą odpowiedzialną za bezpieczeństwo i nie wiesz jak wyjaśnić ten problem osobom mniej obeznanym w technologiach?
Ten odcinek jest właśnie dla Ciebie.
Postaram się w nim wyjaśnić przy użyciu prostych przykładów, jak ataki XSS mogą wpłynąć na biznes – także od tej finansowej strony.
Dzięki temu wytłumaczenie dlaczego warto naprawiać te błędy i dlaczego mogą być one niebezpieczne dla naszej organizacji – powinno być dużo prostsze.
Zaczynajmy.
Skąd bierze się XSS
Każda nowoczesna strona Internetowa składa się z kilku części.
Mamy obrazki, kod CSS który odpowiedzialny jest za wygląd strony, a także kod JavaScript, który definiuje jak cała strona działa.
Kod piszą programiści, którzy pracują dla naszej firmy, bądź też na nasze zlecenie.
Dzięki temu w większości przypadków mamy pewność, że nie mają złych zamiarów i kod przynajmniej w teorii powinien działać tak, jak to zostało uzgodnione.
Oczywiście pomijamy tutaj kwestie błędów, które istnieją w każdej aplikacji w mniejszym bądź też większym stopniu ale przynajmniej z zasady nie powinny być one wprowadzane przez programistów celowo.
Inaczej sprawa się ma jednak w przypadku błędów XSS.
Wtedy to na naszej stronie może znaleźć się kawałek kodu niestworzony przez naszych programistów.
A co za tym idzie nie mamy żadnego wpływu na to co on robi – a to już jest groźne.
Najczęściej w tym kontekście mówi się o możliwości przejęcia konta dowolnego użytkownika.
Ale jak to możliwe?
Po zalogowaniu przy użyciu loginu i hasła, serwer zwraca przeglądarce odpowiednie ciasteczko.
Jest to specjalny identyfikator, na podstawie którego serwer wie, że my to my.
Można to porównać do dowodu tożsamości.
Gdy chcemy wypłacić pieniądze w banku – jesteśmy proszeni o udostępnienie naszego dowodu.
Pracownik banku po jego weryfikacji wie z kim ma do czynienia i jest w stanie udostępnić nam nasze pieniądze.
Podobnie ciasteczka – serwer, który otrzyma takie nasze ciasteczko wie, kim jesteśmy i do jakich funkcji mamy dostęp.
Jeżeli więc atakujący wykradnie ciasteczko użytkownika – może korzystać z portalu podszywając się pod niego.
Skutki cudzego kodu
Skutki zależą od serwisu, który prowadzimy.
Jeżeli celem padnie rządowa strona prezydenta – ktoś może wypuścić w świat kompromitujące informacje.
Gdy wyciekną dane do konta bankowego – atakujący ma dostęp do historii transakcji oraz stanu naszego konta.
W przypadku dostępu do sklepu internetowego – może zmienić ceny produktów, ich stan magazynowy, opisy czy też po prostu numer konta, na który ludzie wpłacają pieniądze.
A jeśli dostanie się do naszej poczty internetowej może przeglądać jej zawartość oraz wysyłać wiadomości do innych użytkowników.
Możliwości jest wiele, wszystko zależy od wyobraźni atakującego.
Ale nie zawsze możliwość wykradzenia ciasteczka jest możliwa.
Wtedy stosuje się metody socjotechniczne – czyli przy pomocy odpowiednich komunikatów, próbuje się przekonać użytkownika, że jakaś wiadomość jest prawdą pomimo tego, że prawdą nie jest.
Najprostszy przykład to zmiana wyglądu strony internetowej.
Jeżeli ktoś posiada dostęp do kodu JavaScript strony – może zmieniać jej treść w locie – to znaczy dodawać, usuwać lub modyfikować jej treść w czasie rzeczywistym.
To tak jakby posiadał magiczną gumkę.
W każdym momencie może wybrać odpowiednie miejsce, usunąć jego treść, a następnie zamienić ją na nową, stworzoną przez siebie.
Taką funkcjonalność można wykorzystać do stworzenia fałszywej strony logowania.
Fałszywej, czyli takiej, która wyświetla się użytkownikowi nawet, jeżeli jest on obecnie zalogowany.
Ale po co? Przecież atakujący ma już dostęp do naszego konta.
Owszem, dostęp może mieć, ale nie zna naszego hasła.
To trochę jak z kradzieżą nowoczesnych telefonów.
W większości przypadków nie wystarczy, że przestępca ukradnie nam nasz telefon.
Aby móc z niego korzystać, musi posiadać nasz kod pin, który pozwoli na odblokowanie wszystkich jego funkcji.
Podobnie tutaj.
Po co kraść hasło
Poznając hasło użytkownika, może je ponownie wykorzystać, chociażby na innym serwisie internetowym.
Często zdarza się bowiem, że używamy tego samego hasła na różnych witrynach.
Jego poznanie zatem znacząco zwiększa wektor ataku.
Przykład: atakujący zaatakował stronę naszej biblioteki, co samo w sobie nie za wiele mu daje.
Ale tego samego hasła używamy również na naszej poczcie internetowej.
Ponieważ podaliśmy je na fałszywej stronie logowania – może on teraz zalogować się także do innych naszych serwisów.
Ale to nie wszystko.
Większość stron pozwala na opcję przypominania hasła.
Operacja ta jest możliwa po potwierdzeniu naszej tożsamości.
A robi się to poprzez kliknięcie w link, który przychodzi na naszą skrzynkę mailową.
A ponieważ przestępca ma już do niej dostęp, może w łatwy sposób zmienić hasła także do innych stron internetowych.
Nie zawsze celem ataku są konkretni użytkownicy.
Podmiana reklam
Zdarza się, że większe pieniądze można zarobić atakując samą firmę.
Sporo stron zarabia obecnie na reklamach internetowych.
Umieszczamy je w różnych miejscach i otrzymujemy pieniądze za każde takie klikniecie.
Ale przecież atakujący kontroluje treść na naszych podstronach – może zatem usunąć nasze reklamy i zamiast nich wprowadzić swoje.
Tym samym on zarabia, a my tracimy.
No ale taka drastyczna zmiana w zarobkach może zostać szybko wykryta.
Jeszcze jakiś czas temu popularne stało się zarabianie na kryptowalutach.
Umieszczono więc na stronie kawałek niewidocznego kodu.
Z punktu widzenia graficznego nie zmieniał on niczego na naszej stronie.
Wpływał jednak na komputery odwiedzających, wykorzystując ich procesory do wykonywania skomplikowanych obliczeń.
Im większa widownia naszej strony tym więcej komputerów pracowało dla atakującego.
A traciliśmy my.
Taki kod powodował bowiem, że komputer bardzo szybko przestawał reagować na polecenia użytkownika, co znacząco wpływa na jego irytację.
Można to porównać do sytuacji, gdy przez pomyłkę otwieramy kilka instancji tej samej aplikacji naraz.
Nasz komputer walczy wtedy o zasoby i chwilę zajmuje mu poukładanie wszystkich zadań i wykonanie wszystkich poleceń.
Tylko, że w przypadku kryptowalut – taka sytuacja ma miejsce cały czas.
W zależności od atakującego, celem niekoniecznie musza być pieniądze.
Deanonimizacji użytkownika
Podobne metody można wykorzystać do deanonimizacji użytkownika, a także wpłynąć na jego prywatność.
Nowoczesne przeglądarki po otrzymaniu zgody od użytkownika pozwalają na nagrywanie jego dźwięku.
Tym samym zewnętrzny podmiot może uzyskać dostęp do potencjalnie prywatnych informacji.
Podobnie z informacjami o geolokalizacji.
Strony z mapami proszą nas o zgodę, aby móc zlokalizować nas w przestrzeni.
Ale o taką samą informację może przecież poprosić sklep internetowy, aby pokazać nam najbliższy punkt odbioru paczek.
W przeszłości zdarzało się, że podatności te były wykorzystywane do ataków, które można przyrównać do rozprzestrzeniania się chorób w normalnym świecie.
XSS worm
Taki kawałek kodu nazywamy XSS worm i widuje się go zazwyczaj na platformach społecznościowych.
Może on posłużyć do promocji jakiejś treści wśród wielu użytkowników jednocześnie.
Przykład: załóżmy, że mamy jakiś produkt, który chcielibyśmy zareklamować na Facebooku.
Standardowo, musimy zapłacić za reklamę, aby nasz post dotarł do jak najszerszej grupy odbiorców.
A co w przypadku błędu typu XSS?
Pozwala on nam na wykonanie dowolnej akcji w imieniu użytkownika.
Kod taki może zatem pobrać listę wszystkich przyjaciół zaatakowanej osoby, a następnie przesłać im link do produktu wraz z krótką informacją.
A ponieważ rozesłany kawałek to również XSS – przyjaciele naszych przyjaciół również otrzymają taką wiadomość, ponieważ nasi przyjaciele po otwarciu wiadomości zarażą również ich.
To tak jak z kichaniem – jeżeli kichniesz na kolegę, to on wróci do domu i zarazi swoje dziecko, które to pójdzie do przedszkola, gdzie zarazi resztę dzieci, które to zarażą swoich rodziców.
A takie epidemie są bardzo trudne do okiełznania.
I nie chodzi tu tylko o straty finansowe dla serwisów, ale także potencjalne straty wizerunkowe.
Złośliwe oprogramowanie
Nasza strona może również posłużyć do dystrybucji złośliwego oprogramowania.
Teoretycznie XSS nie pozwala na wysyłkę jakiegoś pliku na nasz serwer (o ile oczywiście zaatakowany użytkownik nie posiada takich uprawnień).
Ale to niczego nie zmienia.
Załóżmy, że jesteśmy serwisem z wideo online.
Każdy użytkownik wie, że czasami do odtworzenia materiału potrzebna jest aktualizacja oprogramowania, wgranie jakiegoś kodeka, czy też innej aplikacji, aby móc zapoznać się z treścią.
Pomysłowy atakujący może przestać wyświetlać nasze filmy i zamiast nich umieścić informację o konieczności aktualizacji oprogramowania.
Taki odnośnik może prowadzić do zewnętrznego serwera ze złośliwym oprogramowaniem.
A ludzie pretensje będą zgłaszać do nas.
Ucierpi nasza reputacja, bo to my przekierowywaliśmy ich do tego pliku.
Pamiętajmy: reputację buduje się latami, a stracić ją można w jednej chwili.
Atak DDOS
Co więcej przy użyciu naszej strony można zaatakować konkurencję.
Fachowo nazywa się to atakiem DDOS.
Cel jest jeden: zablokować serwery konkurencji tak, aby nie mogły obsługiwać klientów.
W Internecie można odnaleźć ogłoszenia osób zajmujących się tym procederem.
Po przesłaniu pieniędzy i adresu celu – przystępują do działania.
Wykorzystują do tego celu botnet – czyli zespół przejętych komputerów.
W standardowym podejściu zaraża się komputer złośliwym oprogramowaniem i od tego momentu może on wykonywać dowolną komendę przesłaną przez atakującego.
Ale podobny efekt można uzyskać w przeglądarce – o ile tylko w karcie przeglądarki mamy otworzoną kartę z zarażoną witryną.
Co sekundę kod zarażonej witryny zmusza przeglądarkę do wysłania żądania do atakowanej strony.
Dla użytkownika taki proceder jest całkowicie niewidoczny, wszystko dzieje się w tle.
Jedne odwiedziny na sekundę nie wydają się być czymś szczególnym.
Ale pomnóżmy to przez ilość użytkowników danej witryny.
Poza tym wysłanie adresu nie zajmuje dużo łącza, ale już odpowiedź serwera jest zdecydowanie większa, nawet kilkudziesięciokrotnie.
A przesyłanie danych to czas i pieniądz.
No dobrze, ale możesz pomyśleć pomimo tych wszystkich przykładów, że Twojej strony to nie dotyczy, bo wszystkie dane od użytkownika są szyfrowane i nie ma szans na ich poznanie bez odpowiedniego hasła.
Keylogger w JS
A co gdybym powiedział Ci, że nie trzeba znać hasła, jeżeli tylko użytkownik wpisuje te dane na Twojej stronie?
Na nic szyfrowanie, jeżeli dane te można podsłuchać podczas ich wpisywania.
Takie oprogramowanie nazywa się Keylogger – i monitoruje wciśnięte klawisze.
Coś takiego można również napisać za pomocą JavaScript, pamiętając, że możliwe jest monitorowanie wciśniętych klawiszy jedynie na tej jednej konkretnej stronie.
Tak oto możemy poznać numer karty kredytowej użytkownika, jego posty i o wiele, wiele więcej.
Również kopiowanie danych do schowka jest zagrożone.
Nowoczesne przeglądarki umożliwiają dostęp do schowka, jeżeli użytkownik wciśnie na Twojej stronie klawisz Ctrl+C.
Wtedy to można podmienić numer konta, na zupełnie inny.
A to już brzmi interesująco?
Sprawdzasz czy numer konta na stronie się zgadza z tym na fakturze.
Wszystko jest OK więc kopiujesz go do schowka.
A tam niespodzianka – treść się nie zgadza i pieniądze zostaną wysłane zupełnie gdzie indziej.
Warto tu jeszcze wspomnieć o jednej rzeczy.
XSS Auditor
W przeszłości część ataków XSS nie dochodziła do skutku dzięki XSS Auditor.
Było to narzędzie wbudowane w przeglądarkę, które starało się rozpoznać część ataków XSS.
Od pewnego momentu nie jest ono już dalej wspierane i zostało usunięte z przeglądarki Chrome.
Dlaczego? Nie było skuteczne tak, jak mogło by się to na pierwszy rzut oka wydawać.
Bardziej zaawansowani atakujący dalej byli je w stanie ominąć.
Poza tym mechanizm ten był traktowany jako plaster na małą ranę.
Wielu twórców witryn nie naprawiało błędów, twierdząc, że nie ma to większego sensu bo ich użytkownicy byli chronieni.
A to złe podejście.
XSS to bowiem błąd programistów witryny, a nie twórców przeglądarki.
Lepiej go załatać, niż czekać aż ktoś to zrobi za nas.
No bo co z innymi użytkownikami przeglądarek, które takiego mechanizmu w przeszłości nie posiadały?
Traktujemy ich gorzej i zwiększamy ich szansę na atak?
I to już wszystko w tym odcinku.
Mam nadzieje, że teraz już rozumiesz dlaczego podmiana kodu JS może być niebezpieczna i dlaczego powinno się tą podatność naprawić jak najszybciej się da.
