Poniżej znajdują się czynności, które osoba atakująca może zrobić, jeśli istnieje luka w zabezpieczeniach XSS.

• Ad-Jacking - jeśli uda Ci się przechować XSS na stronę internetową, po prostu umieść w niej swoje reklamy, aby zarabiać;)
• Click-Jacking - Możesz utworzyć ukrytą nakładkę na stronie, aby przechwytywać kliknięcia ofiary w celu wykonania złośliwych działań .

• Session Hijacking - do plików cookie HTTP można uzyskać dostęp przez JavaScript, jeśli flaga HTTP ONLY nie jest obecna w plikach cookie.

• Podszywanie się pod treści - JavaScript ma pełny dostęp do kodu aplikacji internetowej po stronie klienta, dzięki czemu można go używać do wyświetlania / modyfikowania żądanej treści.

• Gromadzenie referencji - najfajniejsza część. Możesz użyć fantazyjnego wyskakującego okienka, aby zebrać dane logowania. Oprogramowanie układowe Wi-Fi zostało zaktualizowane, wprowadź ponownie swoje dane uwierzytelniające, aby się uwierzytelnić.

• Wymuszone pobieranie - więc ofiara nie pobiera złośliwego Flash Playera z absolutnie-safe.com? Nie martw się, będziesz mieć więcej szczęścia, próbując wymusić pobranie z zaufanej witryny, którą odwiedza Twoja ofiara.

• Crypto Mining - Tak, możesz użyć procesora ofiary, aby wydobyć trochę bitcoinów dla siebie!

• Omijanie ochrony CSRF - Możesz wysyłać żądania POST za pomocą JavaScript, możesz zbierać i przesyłać token CSRF za pomocą JavaScript, czego jeszcze potrzebujesz?

• Keylogging - Wiesz, co to jest.

• Nagrywanie dźwięku - wymaga autoryzacji od użytkownika, ale masz dostęp do mikrofonu ofiary. Dzięki HTML5 i JavaScript.

• Robienie zdjęć - wymaga autoryzacji od użytkownika, ale masz dostęp do kamery internetowej ofiary. Dzięki HTML5 i JavaScript.

• Geolokalizacja - wymaga autoryzacji od użytkownika, ale masz dostęp do Geolokalizacji ofiary. Dzięki HTML5 i JavaScript. Działa lepiej z urządzeniami wyposażonymi w GPS.

• Kradzież danych pamięci internetowej HTML5 - HTML5 wprowadził nową funkcję, pamięć internetową. Teraz strona internetowa może przechowywać dane w przeglądarce do późniejszego wykorzystania i oczywiście JavaScript może uzyskać dostęp do tego miejsca za pośrednictwem window.localStorage () i window.webStorage () System przeglądarki &

• Odcisk palca - JavaScript sprawia, że ​​znalezienie nazwy przeglądarki, wersji, zainstalowanych wtyczek i ich wersji, systemu operacyjnego, architektury, czasu systemowego, języka i rozdzielczości ekranu to bułka z masłem.

• Skanowanie sieciowe - przeglądarka ofiary może być wykorzystywana do skanowania portów i hostów za pomocą JavaScript.

• Awarie przeglądarek - tak! Możesz zawiesić przeglądarkę, zalewając ją… .stuff.

• Kradzież informacji - pobierz informacje ze strony internetowej i wyślij je na swój serwer. Proste!

• Przekierowanie - możesz użyć javascript, aby przekierować użytkowników na wybraną stronę internetową.

• Tabnapping - Po prostu wymyślna wersja przekierowania. Na przykład, jeśli przez ponad minutę nie odebrano żadnych zdarzeń związanych z klawiaturą lub myszą, może to oznaczać, że użytkownik jest afk i można podstępnie zastąpić obecną stronę internetową fałszywą.

• Przechwytywanie zrzutów ekranu - dzięki HTML5 możesz teraz zrobić zrzut ekranu strony internetowej. Ślepe narzędzia do wykrywania XSS robiły to, zanim było fajnie.

• Wykonaj akcje - kontrolujesz przeglądarkę,

Może przykład z życia pomógłby zrozumieć, jak niebezpieczna może być pozornie niewielka luka w zabezpieczeniach, taka jak XSS.

W ramach oceny bezpieczeństwa mojej firmie zlecono próbę uzyskania dostępu do osobistego dyrektora generalnego e-maile. Udało mi się uzyskać jego osobisty adres e-mail za pośrednictwem jakiegoś OSint, teraz można było przejść do spear phishingu z niestandardową wersją jednego z wielu złośliwego oprogramowania wykradającego informacje, ale przedłużyłem fazę zbierania informacji trochę dłużej. p> Okazało się, że dyrektor generalny kochał łodzie i sprzedawał jedną ze swoich w serwisie sprzedaży łodzi. Strona wydaje się całkiem amatorska, zarejestrowałem się i trochę się wygłupiałem. A co ja znalazłem? Witryna umożliwia zarządzanie hasłem, wypełniając pole hasła bieżącym, zachęcony tym. Zbadam witrynę nieco dokładniej. Natknąłem się na zapisaną lukę w zabezpieczeniach XSS: kiedy odpowiadasz na ofertę, możesz umieścić w niej dowolny kod HTML, w tym skrypty, i zostanie on wykonany w przeglądarce czytnika!

Wydaje się dość „nieszkodliwy”, nie robi t to? Co jeśli połączysz to ze złym zarządzaniem hasłem?

Więc stworzyłem skrypt, który pobierał stronę z hasłem (jest to żądanie wewnątrz domeny, SOP jest spełniony), wyodrębniłem hasło i informacje o kliencie (UA, OS i podobne) i wyślij je do mojego C&C. Następnie zaszczepiłem w CEO poczucie zachęty, ostrożnie pisząc e-mail informujący go o moim „zamiarze” zakupu.

Po dniu otrzymałem hasło używane do logowania się na stronie łodzi. Zgodnie z oczekiwaniami było to to samo hasło używane do ich poczty e-mail (nie było 2FA, nie pamiętam, czy to było jeszcze coś) i udało mi się uzyskać dostęp do poczty internetowej (informacje o kliencie zostały użyte do zasymulowania legalnego dostępu na wypadek, gdyby trzeba było zachować niski profil).

Krótko mówiąc, atak nie jest pojedynczym atomowym krokiem, składa się z małych podbojów. Jeśli dasz swojemu przeciwnikowi miejsce na krok, nigdy nie będziesz wiedział, co może zrobić z tego miejsca. XSS to miejsce dla atakującego, jak widzieliście całkiem sporo.

Kod kontrolowany przez atakującego, który działa w kontekście aplikacji internetowej po stronie klienta, ma pełną kontrolę nad tym, co robi klient, a także może czytać DOM strony HTML itp.

Oznacza to, że może zarówno kraść sekrety, które są na tej stronie (hasła itp.), Jak i robić rzeczy po zalogowaniu się (np. Kupić coś, wysłać groźby bomby w kliencie pocztowym itp.). Zwróć uwagę, że tego rodzaju aktywność często może być ukryta przed klientem, aby nie zdawał sobie sprawy, że jest obecnie atakowany.

Atak XSS nie stanowi zagrożenia dla serwera. To zagrożenie dla powodu, dla którego masz serwer. Nie w sensie technicznym, ale bardzo ludzkim, ponieważ każdy rodzaj ataku XSS pochodzący z Twojej witryny zwykle kończy się Twoją reputacją w toalecie. Kilka przypadków testowych:

• Ktoś przekierowuje z Twojej witryny na fałszywą stronę logowania. Teraz masz potencjalne masowe naruszenie bezpieczeństwa kont użytkowników w Twojej witrynie.
• Ktoś umieścił kryptowalutę w Twojej witrynie. Spowoduje to, że maszyny gości będą pracować w nadgodzinach, a gdy zostaną zauważone, sprawi, że jako administrator systemu będziesz wyglądać na rażąco chciwego i / lub rażąco niekompetentnego. Żaden z nich nie jest dobrym wyglądem.
• Ktoś przekierowuje ruch z Twojej witryny do konkurencji. Nie powinienem musiał wyjaśniać, dlaczego to jest złe.
• Ktoś umieszcza tam trochę javascript, który uniemożliwia korzystanie z witryny lub nawet powoduje awarię przeglądarek. Powtarzam, powinno być oczywiste, dlaczego jest to złe.
• Ktoś umieszcza kod DDOS w Twojej witrynie, aby spróbować ją usunąć lub ją usunąć. Jeśli celujesz w ciebie, powinno być oczywiste, dlaczego jest to złe. Jeśli skierowana jest do kogoś innego, a Twoja witryna zostanie uznana za winną, Twój dostawca usług hostingowych może Cię odciąć, jeśli nie naprawisz witryny z powodu naruszenia umowy.
• Ktoś zastępuje Twoje reklamy własnymi. Jeśli polegasz na przychodach z reklam, kradną je.
• Ktoś używa ich, aby podsłuchiwać Twoich użytkowników. Cześć, naruszenie RODO.

Kiedy XSS po raz pierwszy stał się szeroko znany w społeczności bezpieczeństwa aplikacji internetowych, niektórzy profesjonalni testerzy penetracji byli skłonni uznać XSS za „kiepską” lukę w zabezpieczeniach

źródło: aplikacja internetowa Podręcznik hakerów

XSS to wstrzyknięcie poleceń po stronie klienta, jak wskazał inny użytkownik, może skutkować dowolną czynnością, którą może wykonać użytkownik. Przeważnie XSS jest używany do przechwytywania sesji, gdzie atakujący za pomocą javascript zmusza ofiarę do przesyłania plików cookie sesji na serwer kontrolowany przez atakującego, a stamtąd może wykonać „jazdę sesyjną”.

Ale XSS może również doprowadzić do całkowitego przejęcia aplikacji. Rozważ scenariusz, w którym wstrzykujesz javascript i zostaje on zapisany. Administrator następnie ładuje to do przeglądarki internetowej (zwykle logi lub CMS). Jeśli XSS jest tam obecny, masz teraz tokeny sesji administratora. Dlatego XSS może być bardzo niebezpieczny.

Większość możliwych konsekwencji luk XSS dotyczy użytkownika, a nie serwera. Jeśli więc nie zależy Ci na tym, aby Twój użytkownik przejął swoje konta w Twojej witrynie lub aby użytkownicy widzieli treści w Twojej witrynie, które nie pochodzą z Twojego serwera, zignoruj ​​te luki.

Ale jeśli Twoja użytkownicy mają uprawnienia administratora, wówczas luka w zabezpieczeniach XSS może łatwo doprowadzić do niezamierzonych działań administracyjnych. Klasycznym przypadkiem jest przeglądarka dziennika w obszarze administracyjnym, która nie jest odporna na XSS. Niektóre fragmenty kodu JavaScript w dziennikach dostępu mogą zostać wykonane przez administratorów i wykonać czynności administracyjne na ich koncie. Z tego powodu czasami widzisz fragmenty kodu JavaScript w nagłówkach HTTP botów, które próbują włamać się do Twojej witryny.

Aby podać przykład z prawdziwego życia, w którym XSS został użyty do bezpośredniego przejęcia serwera w incydencie około 10 lat temu (chociaż zapomniałem nazwy (małej / nieistotnej) witryny i wątpię, że już istnieje):

Zgłoś webmasterowi: „W Twojej witrynie jest luka XSS. Powinieneś to naprawić. Jak mam przesłać Ci szczegóły?”

Odpowiedź przyszłego webmastera: „Pokaż mi jak byś tego nadużył. Mój serwer jest super bezpieczny! Spróbuj, jeśli chcesz, ale nie będziesz miał szans. ”

Odpowiedź reportera:„ W takim razie spójrz na mój profil w swojej witrynie. "

Zrobił to webmaster i nagle cała witryna przestała istnieć. Co się stało? Reporter wykorzystał lukę XSS do wstawienia kodu JavaScript na swojej stronie profilowej.

Kod JavaScript (działający w przeglądarce i sesji webmastera) wysyłał żądania do serwera na adres:

1. dodaj nowe konto z najwyższymi uprawnieniami (do celów demonstracyjnych)
2. aby zmienić nazwy plików PHP i tabel SQL na serwerze (witryna miała sekcję administracyjną, która pozwala na to do celów administracyjnych, takich jak aktualizacje lub instalowanie widżetów podobnych do wielu systemów CMS)

Dodatkowe szkody można było wyrządzić, wysyłając do firmy hostingowej żądanie anulowania subskrypcji serwera i domeny oraz przelania pieniędzy z swoje konto bankowe (pod warunkiem, że webmaster był zalogowany do hosta / rejestratora domen / banku i nie miał ochrony przed CSRF, co nie było rzadkością 10 lat temu).

Nie zapomnij także o robakach XSS jak robak MySpace Samy, który rozprzestrzenia się na wszystkich stronach profilowych i może atakować DDoS serwer lub szkodzić użytkownikom.

Wygląda na to, że szukasz niebezpieczeństwa dla serwera (w tym SQL itp.), a nie klienta, więc wiele zagrożeń nie ma zastosowania.

Ale istnieje niebezpieczeństwo serwer z tego, co klient może robić na serwerze. Jeśli klient ma uprawnienia do zmiany bazy danych, osoba atakująca też może. To samo dotyczy wszystkiego, do czego klient ma pozwolenie na serwerze.

XSS sam w sobie jest niebezpieczny w następującym sensie:

• Identyfikator sesji / plik cookie może zostać skradziony, aby uzyskać pełny dostęp do kont ofiar.
• Tymczasowe zniszczenie witryny internetowej. Uruchamianie złośliwych skryptów JS (górnik, złodziej danych kart, rejestrator kluczy itp.)
• Korzystając z frameworków służących do wykorzystywania luk, takich jak Beef, atakujący może wykonywać niektóre wywołania OS, takie jak zdalne otwieranie kamer internetowych, włączanie mikrofonu, przekierowywanie stron internetowych na złośliwe witryny itp.
• Czasami XSS może być używany do kradzieży tajnych tokenów ofiar, tokenów CSRF (crosssite request fałszerstwa), kluczy API, a następnie można przeprowadzić dalszą eksploatację, taką jak ataki CSRF.

Ten blog i ten pokazują, w jaki sposób atak XSS jest używany do wykonania wstrzyknięcia SQL w aplikacji internetowej.

Z innych odpowiedzi masz bardzo dobrą listę technicznych powodów, dla których XSS jest problemem. Podam inną perspektywę.

XSS to luka, którą można łatwo wprowadzić do kodu i którą można wykryć za pomocą skanerów. Jest to prawdopodobnie jeden z powodów, dla których jest on stosunkowo dobrze znany „ogółowi społeczeństwa”, w tym dziennikarzom (w znaczeniu „Słyszałem o tym”).

Jeśli jeśli masz jedną publicznie dostępną, można ją opisać jako

Sai Kumar LLC ma wyjątkowo podatną witrynę, ponieważ zawiera XSS.XSS jest bardzo niebezpieczną luką w zabezpieczeniach. Bardzo. Jest.

Umożliwia kradzież Twoich danych. To robi. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.

Następnie możesz wykonać wszystkie rodzaje tańca brzucha, wyjaśniając, że to nie jest luka w zabezpieczeniach, errata zostanie opublikowana czcionką 3 pt na stronie 74, wyszarzona.

Dlatego systematycznie podnoszę wyniki CVSS wyników XSS na moich publicznych stronach internetowych (gdy zostaną ujawnione przez pentest, skanowanie lub inne testy).

Przechowywane skrypty między witrynami są bardzo ryzykowne z wielu powodów: ładunek nie jest już widoczny dla filtru XSS przeglądarki. Użytkownicy mogą przypadkowo uruchomić ładunek, jeśli przejdą do strony, której dotyczy problem, podczas gdy spreparowany adres URL lub precyzyjne dane wejściowe formularza będą wymagane do wykorzystania odzwierciedlonego XSS.