Nachfolgend sind die Maßnahmen aufgeführt, die ein Angreifer bei einer XSS-Sicherheitsanfälligkeit ergreifen kann.

• Ad-Jacking - Wenn Sie es schaffen, XSS auf einem zu speichern Website, fügen Sie einfach Ihre Anzeigen ein, um Geld zu verdienen;)
• Click-Jacking - Sie können eine versteckte Überlagerung auf einer Seite erstellen, um Klicks des Opfers zu entführen und böswillige Aktionen auszuführen .

• Sitzungsentführung - Auf HTTP-Cookies kann über JavaScript zugegriffen werden, wenn das Cookie-NUR-Flag in den Cookies nicht vorhanden ist.

• Spoofing von Inhalten - JavaScript hat vollen Zugriff auf den clientseitigen Code einer Web-App und kann daher den gewünschten Inhalt anzeigen / ändern.

• Ernte von Anmeldeinformationen - Der unterhaltsamste Teil. Sie können ein ausgefallenes Popup verwenden, um Anmeldeinformationen zu sammeln. Die WiFi-Firmware wurde aktualisiert. Geben Sie Ihre Anmeldeinformationen zur Authentifizierung erneut ein.

• Erzwungene Downloads - Das Opfer lädt Ihren böswilligen Flash-Player also nicht von herunter absolut-safe.com? Keine Sorge, Sie werden mehr Glück haben, wenn Sie versuchen, einen Download von der vertrauenswürdigen Website zu erzwingen, die Ihr Opfer besucht.

• Crypto Mining - Ja, Sie können die CPU des Opfers verwenden, um Bitcoin für Sie abzubauen!

• CSRF-Schutz umgehen - Sie können POST-Anfragen mit JavaScript stellen, Sie können ein CSRF-Token mit JavaScript sammeln und senden. Was benötigen Sie noch?

• Keylogging - Sie wissen, was das ist.

• Audio aufnehmen - Es ist eine Autorisierung des Benutzers erforderlich, Sie greifen jedoch auf das Mikrofon des Opfers zu. Dank HTML5 und JavaScript.

• Fotografieren - Es ist eine Autorisierung des Benutzers erforderlich, Sie greifen jedoch auf die Webcam des Opfers zu. Dank HTML5 und JavaScript.

• Geostandort - Es ist eine Autorisierung des Benutzers erforderlich, Sie greifen jedoch auf den Geostandort des Opfers zu. Dank HTML5 und JavaScript. Funktioniert besser mit Geräten mit GPS.

• Diebstahl von HTML5-Webspeicherdaten - HTML5 hat eine neue Funktion eingeführt, den Webspeicher. Jetzt kann eine Website Daten zur späteren Verwendung im Browser speichern, und JavaScript kann natürlich über window.localStorage () und window.webStorage () auf diesen Speicher zugreifen. Browser & System

• Fingerabdruck - Mit JavaScript ist es ein Kinderspiel, den Namen, die Version, die installierten Plugins und deren Versionen, das Betriebssystem, die Architektur, die Systemzeit, die Sprache und die Bildschirmauflösung Ihres Browsers zu ermitteln.

• Netzwerkscanning - Der Browser des Opfers kann zum Scannen von Ports und Hosts mit JavaScript missbraucht werden.

• Absturz von Browsern - Ja! Sie können den Browser zum Absturz bringen, indem Sie ihn mit ... überfluten.

• Informationen stehlen - Informationen von der Webseite abrufen und an Ihren Server senden. Einfach!

• Weiterleiten - Sie können Javascript verwenden, um Benutzer auf eine Webseite Ihrer Wahl umzuleiten.

• Tabnapping - Nur eine ausgefallene Version der Umleitung. Wenn beispielsweise länger als eine Minute keine Tastatur- oder Mausereignisse empfangen wurden, kann dies bedeuten, dass der Benutzer afk ist und Sie die aktuelle Webseite problemlos durch eine gefälschte ersetzen können.

• Screenshots erfassen - Dank HTML5 können Sie jetzt Screenshots einer Webseite erstellen. Blinde XSS-Erkennungstools haben dies getan, bevor es cool war.

• Aktionen ausführen - Sie steuern den Browser,

Vielleicht hilft ein Beispiel aus dem wirklichen Leben zu verstehen, wie gefährlich eine anscheinend geringfügige Sicherheitslücke wie XSS sein kann.

Im Rahmen einer Sicherheitsbewertung wurde mein Unternehmen beauftragt, auf das Personal des CEO zuzugreifen E-Mails. Ich habe es geschafft, seine persönliche E-Mail-Adresse über ein OSint zu erhalten. Jetzt könnte man mit einer benutzerdefinierten Version einer der vielen Info-Stealer-Malware ein Spear-Phishing durchführen, aber ich habe die Phase des Sammelns von Informationen etwas länger verlängert.

Scheint ziemlich "harmlos" zu sein, nicht wahr? nicht wahr? Was ist, wenn Sie es mit der schlechten Verwaltung des Kennworts kombinieren?

Also habe ich ein Skript erstellt, das die Kennwortseite abruft (es ist eine domäneninterne Anforderung, SOP ist erfüllt), das Kennwort und die Clientinformationen extrahiert (UA, OS und ähnliches) und sende es an einen meiner C&C. Dann wurde dem CEO ein Gefühl des Drangs vermittelt, indem er sorgfältig eine E-Mail schrieb, in der er über meine "Kaufabsicht" informiert wurde.

Nach einem Tag erhielt ich das Passwort, mit dem sie sich auf der Bootsseite angemeldet hatten. Wie erwartet war es das gleiche Passwort, das für ihre E-Mail verwendet wurde (es gab kein 2FA, ich kann mich nicht erinnern, ob es noch etwas war) und ich konnte auf das Webmail zugreifen (die Client-Informationen wurden verwendet, um einen legitimen Zugriff zu simulieren , falls es notwendig war, sich zurück zu halten).

Lange Rede, kurzer Sinn, ein Angriff ist kein einzelner atomarer Schritt, sondern besteht aus kleinen Eroberern. Wenn Sie Ihrem Gegner Raum für einen Schritt geben, werden Sie nie wissen, was er von dort aus tun kann. Ein XSS ist Platz für den Angreifer, wie Sie schon gesehen haben.

Angreifergesteuerter Code, der im Kontext der Webanwendung auf der Clientseite ausgeführt wird, hat die volle Kontrolle darüber, was der Client tut, und kann auch das DOM der HTML-Seite usw. lesen.

Dies bedeutet, dass es sowohl Geheimnisse stehlen kann, die sich auf dieser Seite befinden (Passwörter usw.), als auch Dinge tun kann, die als angemeldeter Client gelten (wie etwas kaufen, Bombenbedrohungen in einem Mail-Client senden usw.). Beachten Sie, dass diese Art von Aktivität häufig vor dem Kunden verborgen sein kann, sodass er nicht merkt, dass er gerade angegriffen wird.

Ein XSS-Angriff ist keine Gefahr für den Server. Es ist eine Gefahr für den Grund, warum Sie einen Server haben. Nicht in technischer, sondern in menschlicher Hinsicht, da jede Art von XSS-Angriff, die von Ihrer Website ausgeht, normalerweise mit Ihrem Ruf auf der Toilette endet. Einige Testfälle:

• Jemand leitet von Ihrer Website zu einer gefälschten Anmeldeseite weiter. Jetzt haben Sie eine potenzielle Massensicherheitsverletzung von Benutzerkonten auf Ihrer Site.
• Jemand platziert einen Cryptominer auf Ihrer Site. Dadurch arbeiten die Maschinen Ihrer Besucher über die Zeit hinaus und wenn Sie entdeckt werden, sehen Sie als Systemadministrator entweder grob gierig und / oder grob inkompetent aus. Beides sieht nicht gut aus.
• Jemand leitet den Datenverkehr von Ihrer Website an einen Konkurrenten weiter. Ich sollte nicht erklären müssen, warum dies schlecht ist.
• Jemand fügt dort Javascript ein, das Ihre Website unbrauchbar macht oder sogar Browser zum Absturz bringt. Auch hier sollte klar sein, warum dies schlecht ist.
• Jemand fügt DDOS-Code in Ihre Site ein, um zu versuchen, Ihre Site oder einen Dritten zu entfernen. Wenn auf Sie gerichtet, sollte klar sein, warum dies schlecht ist. Wenn Sie sich an eine andere Person richten und Ihre Website als schuldhaft eingestuft wird, kann Ihr Hosting-Anbieter Sie abschneiden, wenn Sie Ihre Website nicht wegen Vertragsbruch reparieren.
• Jemand ersetzt Ihre Anzeigen durch seine eigenen. Wenn Sie sich auf Werbeeinnahmen verlassen, stehlen sie diese Einnahmen.
• Jemand verwendet sie, um Ihre Nutzer zu beschnüffeln. Hel-lo, Verstoß gegen die DSGVO.

Als XSS zum ersten Mal in der Community der Webanwendungssicherheit allgemein bekannt wurde, neigten einige professionelle Penetrationstester dazu, XSS als "lahme" Sicherheitslücke zu betrachten.

Quelle: Webanwendung Hackers Handbook

XSS ist eine Befehlsinjektion der Clientseite, wie der andere Benutzer hervorhob. Sie kann zu jeder Aktion führen, die vom Benutzer ausgeführt werden kann. Meistens wird XSS für Sitzungsentführungen verwendet, bei denen der Angreifer mithilfe von Javascript das Opfer dazu bringt, Sitzungscookies an einen vom Angreifer kontrollierten Server zu übertragen, und von dort aus kann der Angreifer "Sitzungsreiten" durchführen.

XSS kann jedoch auch zu einer vollständigen Anwendungsübernahme führen. Stellen Sie sich ein Szenario vor, in dem Sie Javascript injizieren und es gespeichert wird. Der Administrator lädt das dann in einen Webbrowser (normalerweise Protokolle oder CMS). Wenn dort ein XSS vorhanden ist, haben Sie jetzt die Administrationssitzungstoken. Deshalb kann XSS sehr gefährlich sein.

Die meisten möglichen Folgen von XSS-Sicherheitslücken betreffen den Benutzer und nicht Ihren Server. Wenn Sie sich also nicht darum kümmern, dass Ihr Benutzer seine Konten auf Ihrer Website kompromittiert oder Ihre Benutzer Inhalte auf Ihrer Website sehen, die nicht von Ihrem Server stammen, ignorieren Sie diese Sicherheitsanfälligkeiten.

Aber wenn Ihre Benutzer haben Administratorrechte. Eine XSS-Sicherheitsanfälligkeit kann leicht zu unbeabsichtigten Administratoraktionen führen. Ein klassischer Fall ist ein Protokoll-Viewer in Ihrem Admin-Bereich, der nicht XSS-sicher ist. Einige Javascript-Snippets in Ihren Zugriffsprotokollen werden möglicherweise von Ihren Administratoren ausgeführt und führen unter ihrem Konto administrative Aktionen aus. Aus diesem Grund werden in den HTTP-Headern der Bots, die versuchen, Ihre Website zu hacken, manchmal Javascript-Schnipsel angezeigt.

Um Ihnen ein Beispiel aus dem wirklichen Leben zu geben, bei dem XSS bei einem Vorfall vor etwa 10 Jahren verwendet wurde, um den Server direkt zu übernehmen (obwohl ich den Namen der (kleinen / unwichtigen) Website vergessen habe und bezweifle, dass er noch existiert):

Bericht an den Webmaster: "Es gibt eine XSS-Sicherheitslücke auf Ihrer Website. Sie sollten dies beheben. Wie soll ich Ihnen die Details senden?"

Antwort des Möchtegern-Webmasters: "Zeigen Sie es mir Mein Server ist super sicher! Probieren Sie es aus, wenn Sie möchten, aber Sie haben keine Chance. "

Antwort des Reporters:" Dann werfen Sie einen Blick auf meine Profilseite auf Ihrer Website. "

Der Webmaster hat dies getan und plötzlich war die gesamte Website tot. Was ist passiert? Der Reporter hat eine XSS-Sicherheitsanfälligkeit verwendet, um JavaScript-Code auf seiner Profilseite einzufügen.

Der JavaScript-Code (der im Browser und in der Sitzung des Webmasters ausgeführt wird) hat Anforderungen an den Server gesendet an:

1. Fügen Sie ein neues Konto mit den höchsten Rechten hinzu (zu Demonstrationszwecken)
2. , um PHP-Dateien und SQL-Tabellen auf dem Server umzubenennen (die Website verfügte über einen Administrationsbereich, der dies für Administrationszwecke wie Updates ermöglichte oder Installieren von Widgets ähnlich vielen CMS-Systemen)
ol>

Zusätzlicher Schaden könnte durch Senden einer Anfrage an das Hosting-Unternehmen entstanden sein, das Abonnement des Servers und der Domain zu kündigen und Geld von zu überweisen sein Bankkonto (vorausgesetzt, der Webmaster war beim Hoster / Domain-Registrar / der Bank angemeldet und hatte keinen CSRF-Schutz, was vor 10 Jahren nicht ungewöhnlich war).

Vergessen Sie auch nicht die XSS-Würmer wie der MySpace-Wurm Samy, der sich über alle Profilseiten verteilt und möglicherweise Ihren Server DDOS oder Ihre Benutzer schädigt.

Es sieht so aus, als würden Sie nach einer Gefahr für den Server (einschließlich SQL usw.) suchen, nicht für den Client. Daher bestehen viele Gefahren nicht.

Es besteht jedoch eine Gefahr für der Server von dem, was der Client auf dem Server tun darf. Wenn der Client die Berechtigung zum Ändern der Datenbank hat, kann dies auch ein Angreifer tun. Gleiches gilt für alles, was ein Client auf dem Server tun darf.

XSS selbst ist in folgendem Sinne gefährlich:

• Sitzungs-ID / Cookie kann Diebstahl sein, um vollen Zugriff auf Opferkonten zu erhalten.
• Vorübergehende Verunstaltung der Website. Ausführen bösartiger JS-Skripte (Miner, Kartendaten-Stealer, Key-Logger usw.)
• Mit Exploitation-Frameworks wie Beef kann ein Angreifer einige Betriebssystemaufrufe ausführen, z. B. das Öffnen von Webcams aus der Ferne, das Umschalten des Mikrofons, das Umleiten von Websites zu bösartigen Websites usw.
• Manchmal kann XSS verwendet werden, um geheime Token von Opfern, CSRF-Token (Crosssite Request Forgery), API-Schlüssel und dann weitere Ausnutzungen wie CSRF-Angriffe zu stehlen.

Dieser Blog und dieser zeigen, wie XSS-Angriffe verwendet werden, um eine SQL-Injection in einer Webanwendung durchzuführen.

Sie haben aus anderen Antworten eine sehr gute Liste technischer Gründe, warum XSS ein Problem ist. Ich werde eine andere Perspektive geben.

XSS ist eine Sicherheitslücke, die sich leicht in Ihren Code einfügen lässt und von Scannern entdeckt werden kann. Dies ist wahrscheinlich einer der Gründe, warum es der "allgemeinen Öffentlichkeit", einschließlich Journalisten (im Sinne von "Ich habe davon gehört") relativ gut bekannt ist.

If Wenn Sie eine öffentlich verfügbare haben, kann diese als

beschrieben werden. Sai Kumar LLC hat eine extrem anfällige Site, da eine XSS.XSS eine sehr gefährliche Sicherheitsanfälligkeit darstellt. Sehr. Dies ist der Fall.

Damit können alle Daten gestohlen werden. Es tut. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.

Sie können dann alle Arten von Bauchtanz machen und erklären, dass es sich nicht um die Sicherheitsanfälligkeit handelt >

Aus diesem Grund erhöhe ich systematisch das CVSS von XSS-Ergebnissen auf meinen öffentlichen Websites (wenn sie durch einen Pentest, einen Scan oder andere Tests aufgedeckt werden).

Gespeichertes Cross-Site-Scripting ist aus verschiedenen Gründen sehr riskant: Die Nutzdaten sind für den XSS-Filter des Browsers nicht mehr sichtbar. Benutzer können zufällig die Nutzdaten auslösen, wenn sie zur betroffenen Seite gehen, während eine gestaltete URL oder genaue Formulareingaben erforderlich sind, um reflektiertes XSS auszunutzen.