it-swarm.com.de

Wie gefährlich ist XSS?

Ich bin Softwareentwickler und habe viele Videos über XSS gesehen.

Aber ich verstehe nicht, wie gefährlich es ist, wenn es auf der Clientseite ausgeführt wird und nicht auf der Serverseite ausgeführt wird, die die Datenbanken und viele wichtige Dateien enthält.

38
Sai Kumar

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

  • Ad-Jacking - Wenn Sie es schaffen, XSS auf einer Website zu speichern, 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.
  • Session Hijacking - Auf HTTP-Cookies kann über JavaScript zugegriffen werden, wenn das HTTP ONLY-Flag in den Cookies nicht vorhanden ist.

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

  • Credential Harvesting - Der lustigste Teil. Sie können ein ausgefallenes Popup verwenden, um Anmeldeinformationen zu sammeln. Die WLAN-Firmware wurde aktualisiert. Geben Sie Ihre Anmeldeinformationen zur Authentifizierung erneut ein.

  • Forced Downloads - Das Opfer lädt Ihren böswilligen Flash-Player also nicht von absolut-safe.com herunter? 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 umgehen Schutz - 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 erfordert eine Autorisierung des Benutzers, aber Sie greifen auf das Mikrofon des Opfers zu. Dank HTML5 und JavaScript.

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

  • Geo-Standort - Es ist eine Autorisierung des Benutzers erforderlich, aber Sie greifen auf den Geo-Standort 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 natürlich kann JavaScript über window.localStorage () und window.webStorage () Browser & System auf diesen Speicher zugreifen

  • Fingerprinting - 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 finden.

  • Network Scanning - 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 sie 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 durch eine gefälschte ersetzen können.

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

  • Aktionen ausführen - Sie steuern den Browser,

92
Goron

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

Im Rahmen einer Sicherheitsbewertung wurde mein Unternehmen beauftragt, auf die persönlichen E-Mails des CEO zuzugreifen.
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.

Es stellte sich heraus, dass der CEO Boote liebte und eines von ihnen auf einer Bootsverkaufsstelle verkaufte.
Die Seite scheint ziemlich amateurhaft zu sein, ich habe mich registriert und ein bisschen herumgespielt. Und was habe ich gefunden?
Auf der Site können Sie Ihr Passwort verwalten, indem Sie ein Passwortfeld mit dem aktuellen ausfüllen. Dies wird durch die Website noch etwas genauer untersucht.
Ich bin auf eine gespeicherte XSS-Sicherheitsanfälligkeit gestoßen: Wenn Sie ein Angebot beantworten, können Sie beliebigen HTML-Code, einschließlich Skripten, darin einfügen, der im Reader-Browser ausgeführt wird!

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

Also habe ich ein Skript erstellt, das die Kennwortseite abgerufen hat (es ist eine domäneninterne Anforderung, SOP ist erfüllt), das Kennwort und die Clientinformationen (UA, OS und ähnliches) extrahiert und an gesendet hat ein C & C von mir.
Dann erweckte der CEO ein Gefühl des Drangs, 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 Kundeninformationen wurden verwendet um einen legitimen Zugang zu simulieren, falls es notwendig war, sich zurück zu halten).

Kurz gesagt, 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.

34
Margaret Bloom

Angreifergesteuerter Code, der auf der Clientseite im Kontext der Webanwendung 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 als angemeldeter Client (z. B. 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.

25
Steffen Ullrich

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 Website.
  • Jemand stellt einen Cryptominer auf Ihre 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 das 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 das 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 eigene. Wenn Sie sich auf Werbeeinnahmen verlassen, stehlen sie diese Einnahmen.
  • Jemand benutzt es, um Ihre Benutzer zu beschnüffeln. Hel-lo, Verstoß gegen die DSGVO.
11
520

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: Web Application 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 aber 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 Admin-Sitzungstoken. Deshalb kann XSS sehr gefährlich sein.

10
Vipul Nair

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

Wenn Ihre Benutzer jedoch über Administratorrechte verfügen, kann eine XSS-Sicherheitsanfälligkeit leicht zu unbeabsichtigten Administratoraktionen führen. Ein klassischer Fall ist ein Protokoll-Viewer in Ihrem Administrationsbereich, 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 sehen Sie manchmal Javascript-Schnipsel in den HTTP-Headern der Bots, die versuchen, Ihre Website zu hacken.

8
Philipp

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 sie noch existiert):

Bericht an den Webmaster: "Auf Ihrer Website liegt eine XSS-Sicherheitsanfälligkeit vor. Sie sollten dies beheben. Wie soll ich Ihnen die Details senden?"

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

Antwort des Reporters: "Dann schauen Sie sich meine Profilseite auf Ihrer Website an."

Der Webmaster tat dies und plötzlich war die gesamte Website tot. Was ist passiert? Der Reporter verwendete eine XSS-Sicherheitsanfälligkeit, 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. hinzufügen eines neuen Kontos mit höchsten Rechten (zu Demonstrationszwecken)
  2. um PHP-Dateien und SQL-Tabellen auf dem Server umzubenennen (die Website hatte einen Administrationsbereich, der dies für Administrationszwecke wie Updates oder die Installation von Widgets ähnlich vielen CMS-Systemen ermöglichte).

Zusätzlicher Schaden hätte entstehen können, wenn eine Anfrage an das Hosting-Unternehmen gesendet worden wäre, das Abonnement des Servers und der Domain zu kündigen und Geld von seinem Bankkonto zu überweisen (vorausgesetzt, der Webmaster war beim Hoster/Domain-Registrar/der Bank angemeldet und hatte keine CSRF-Schutz, der vor 10 Jahren nicht ungewöhnlich war).

Vergessen Sie auch nicht XSS-Würmer wie der MySpace-Wurm Samy , die sich über alle Profilseiten verteilen und Ihren Server DDOS oder Ihre Benutzer schädigen können.

4
H. Idden

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 gelten viele Gefahren nicht.

Es besteht jedoch die Gefahr für den 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.

3
User42

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.)
  • Mithilfe von Exploitation-Frameworks wie Beef kann ein Angreifer einige Betriebssystemaufrufe ausführen, z. B. das Remote-Öffnen von Webcams, das Drehen des Mikrofons, das Umleiten aller Websites zu schädlichen Websites usw.
  • Manchmal kann XSS verwendet werden, um geheime Token von Opfern, CSRF-Token (Cross Site Request Forgery), API-Schlüssel und weitere Ausnutzungen wie CSRF-Angriffe zu stehlen.

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

1
Kailash

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

XSS ist eine Sicherheitsanfälligkeit, 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 relativ bekannt für die "breite Öffentlichkeit", einschließlich Journalisten (im Sinne von "Ich habe davon gehört") ist.

Wenn Sie eine öffentlich verfügbar haben, kann diese als beschrieben werden

Sai Kumar LLC hat eine extrem gefährdete Site, da es eine XSS hat. XSS ist eine sehr gefährliche Sicherheitsanfälligkeit. Sehr. Es ist.

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

Sie können dann alle Arten von Bauchtanz machen und erklären, dass es sich nicht um die Sicherheitslücke handelt. Das Erratum wird in der Schriftart 3 pt auf Seite 74 veröffentlicht, die ausgegraut ist.

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).

0
WoJ

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.

0
Tatum