I01 – Verwendung von Skripten auf Cross-Site (XSS)
Celia Catalán
.png)
Allgemein bezeichnet durch ihr
englische Nomenklatur, Cross-Site Scripting, diese Art von
Die Verwundbarkeit in Anwendungen wird oft von den
Entwicklungsteams der Unternehmen, weil sie traditionell assoziiert wurden
a rein browserbasierte Angriffe, die den Kunden betreffen, ohne darüber hinauszugehen
irgendein Link als Phishing-Versuch usw. Aber die Realität ist, dass diese Art
von Angriffen, insbesondere in Kombination mit der Ausbeutung anderer
vorhandene Schwachstellen können einen erheblichen Nachteil verursachen.
Bestehen hauptsächlich aus der
Code-Injection (in der Regel JavaScript, obwohl auch vbscript
in konkreten Fällen), im Inhalt von Anwendungen oder Webseiten, die andere
Benutzer können sehen. Mit diesem Code können Daten gestohlen werden.
sensibel, wie Cookies oder Anmeldeinformationen, den Benutzer auf Websites umleiten
böswillig, oder die Identität des betroffenen Benutzers zu übernehmen, um durchzuführen
Aktionen in seinem Namen ohne seine Zustimmung.
Es gibt verschiedene Arten von XSS,
"insbesondere drei große Klassifikationen hervorhebend, die im Folgenden detailliert werden."
Fortsetzung.
Dazu, und bevor wir anfangen, wird
wird eine Anwendung mit bestimmten aktivierten Schwachstellen verwenden (in diesem
Fälle, die sich auf XSS beziehen), zum Lernen. Die Anwendung besteht aus einem
grundlegendes Login-Formular, bei dem man entweder mit Benutzer- oder
Verwaltung zu einem Panel, von wo aus Artikel mit ihrer verwaltet werden.
Preis und im Falle des Administrators, die Verwaltung der Benutzer der
Anwendung, sowie andere Aspekte.
Arten
Reflektiertes XSS
Es tritt im Wesentlichen auf, wenn die Benutzereingabe verarbeitet und direkt auf der Webseite angezeigt wird, ohne ordnungsgemäß validiert oder kodiert zu werden. Dies würde die Injektion von Code ermöglichen, sodass, wenn diese Anfrage ausgeführt wird, das Ergebnis dieser Injektion angezeigt wird. Auf diese Weise könnte die URL (vielleicht verborgen unter einem URL-Shortener, die dem Benutzer, dem Ziel des Angriffs, gesendet wird) gesendet werden. So würde der Benutzer, beim Ausführen dieses Links, auch den in der URL enthaltenen JavaScript-Code ausführen, der eine Weiterleitung zur Website des Angreifers sein könnte, wo beispielsweise das Stehlen des Sitzungscookies des Benutzers auf der aktuellen Website erfolgen würde. Ein weiteres Beispiel wäre die Ausführung eines bösartigen "Hooks" gegen den Webbrowser des Opfers, der ab diesem Moment vom Angreifer kontrolliert wird (zum Beispiel über die Anwendung Beef, ein recht bekanntes Framework für die Webausnutzung).
So, zurück zur erwähnten verwundbaren Anwendung, wenn man im Abschnitt der Artikelliste überprüft, das Suchfeld, das es dem Benutzer ermöglicht, nach bestimmten Artikeln zu suchen:
- "Mit der Anmeldung bei der Anwendung als user1 können die Artikel dieses Benutzers in der Artikelliste über das Menü "Verwalten Sie Ihre Artikel" aufgerufen werden."
- Wenn nach einem Artikel (Name oder Beschreibung) gesucht wird, der existiert, zum Beispiel "Artikel 1":
Wie man sehen kann, spiegelt sich das Ergebnis in der Antwort wider.
- Jetzt wird versucht zu suchen für ein Skript, um zu sehen, ob der Browser es als Code interpretiert oder nicht die Antwort:
- HTML-Code injizieren (zum Beispiel die typische Kopfzeile zwischen den Tags
...
):
Hinweis darauf, dass es zumindest den HTML-Code ohne Filter interpretiert und HTML-Code zulässt, der vom Browser interpretiert wird.
- JavaScript-Code injizieren. Es wird nicht mit den typischen Nachrichten erreicht. , aber es gibt unzählige Payloads, wobei die Seite von PortSwigger Academy ein guter Anhaltspunkt ist. Oder man probiert verschiedene URL-Codierungen aus. Einer der möglichen Payloads wäre zum Beispiel, ein HTML-Objekt vom Typ Bild zu injizieren, dessen Ladefehler die Ausführung eines Skripts auslöst (und da, um es zu testen, das typische Alert):
A
B
- "Die Anfrage mit BurpSuite abfangen, wird die Antwort analysiert, die die Suche tatsächlich erhält, die das Ergebnis über den Parameter search via Ajax laden wird." items_search.php:
Beim Zurücksenden der Antwort an den Browser kann die Schwachstelle überprüft werden:
- Der nächste Schritt wäre beispielsweise, einen kleinen Webdienst auf der angreifenden Maschine einzurichten, sodass der Payload leicht modifiziert wird (zum Beispiel durch um das Cookie des Benutzers zu stehlen, der diese Anfrage weiterleitet. Zum Beispiel, wenn die URL mit dem Payload im codierten Suchparameter an den Administrator der Website gesendet wird, nachdem sie in einen URL-Shortener eingegeben wurde.
Gespeichertes XSS
Dies ist eine der kritischsten Schwachstellen innerhalb der verschiedenen Arten von XSS, da es der einzige Fall ist, in dem die Injektion persistent sein kann, da der schädliche Code dauerhaft auf dem Server gespeichert wird und alle Benutzer betrifft, die den Inhalt anzeigen, nicht nur diejenigen, die auf den schädlichen Link klicken. Das heißt, es gibt eine Interaktion mit dem Server, sodass es mit anderen Schwachstellen kombiniert werden könnte, um sogar den Zugriff darauf zu kontrollieren. Es ist der typische Fall von Kommentarfeldern auf einer Website usw. Obwohl es auch in anderen Datentypen auftreten könnte, wie in Tabellen, die zuvor vom Benutzer eingegebene Ergebnisse speichern, bei denen die Felder nicht ordnungsgemäß validiert wurden.
Zurück zum vorherigen Beispiel der anfälligen Anwendung. In der Verwaltung der Artikel ist zu erkennen, dass es einen Button zur Erstellung neuer Artikel (Add New Item) gibt. Wenn es gelingt, Code in eines der Felder des neuen Artikels einzuschleusen (entweder über jedes Feld oder durch Abfangen der Anfrage mit einem Web-Proxy), wobei die URL-Codierung von Leerzeichen und anderen Sonderzeichen berücksichtigt wird, wird dieses XSS für alle Benutzer der Anwendung gespeichert.
- Nachdem Sie sich mit einem anderen Benutzer (user2) angemeldet haben, geht es jetzt darum, ein bestimmtes XSS einzufügen, um zu testen, ob die Seite an dieser Stelle anfällig ist. Zum Beispiel, im gleichen Beispiel wie zuvor, ist es erlaubt, neue Artikel zu erstellen. Wenn ein Payload vom Typ in das Beschreibungsfeld eingefügt wird (das lang genug ist, um die erforderlichen Zeichen einzufügen). Beim Speichern des Artikels:
- "Sobald festgestellt wurde, dass es anfällig ist, wird der Artikel entfernt (oder bearbeitet, und die Beschreibung wird ersetzt) und ein anderer erstellt, der das Ergebnis nicht direkt auf dem Bildschirm anzeigt, sondern beispielsweise das Cookie des Benutzers an einen Webserver sendet, der auf der angreifenden Maschine läuft, mit dem folgenden Payload:"
Beim Ausführen der Änderung/Hinzufügung wird in der resultierenden Tabelle scheinbar nichts Ungewöhnliches zu beobachten sein:
Dennoch, auf dem Webserver, der auf der angreifenden Maschine läuft:
- Wenn der Administratorbenutzer, der Zugriff auf alle Artikel hat, diese Seite öffnet:
und das vom Angreifer ausgeführte Skript wird lautlos gestartet, das Cookie des Administrators wird als Teil des Parameters der an den Webserver des Angreifers gesendeten Anfrage angezeigt:
Der Unterschied (und die Kritikalität) im Vergleich zu reflected XSS ist bemerkenswert: Jeder Benutzer, der Zugriff auf diesen Datensatz hat, wird betroffen sein, während im Fall von reflected XSS der Versand des bösartigen Links an jeden der Zielbenutzer dieses Angriffs erforderlich wäre.
- Ebenso könnte dieses Skript durch ein hook.js von Beef ersetzt werden, um den Browser der Benutzer zu steuern, die sich mit dieser Seite verbinden, oder um ausgefeiltere Skripte auszuführen, die andere Informationen des Webservers gefährden könnten.
DOM-basiertes XSS
Im DOM-basierten XSS (Document Object Model) wird der schädliche Code direkt auf der Client-Seite ausgeführt, indem das DOM des Browsers manipuliert wird, ohne mit dem Server zu interagieren. So wird eine Manipulation oder Modifikation des dynamischen Inhalts der Seite vorgenommen, indem JavaScript-Code auf dem Client in jenen Parametern oder Feldern der Seite ausgeführt wird, die nicht korrekt codiert oder validiert wurden. So werden alle Benutzer, die die manipulierte Seite aufrufen, von dieser Art von Angriff betroffen sein.
In der Beispielanwendung, wenn ein Benutzer sich auf der Website anmeldet, wird ihm als Übergang eine Willkommensnachricht angezeigt, die direkt und ohne Validierung den Namen des angemeldeten Benutzers in ein .innerHTML des HTML-Objekts injiziert, das für die Willkommensnachricht vorgesehen ist.
Man kann dieses .innerHTML manipulieren, indem man das entsprechende Skript injiziert, sodass der DOM der Antwort zur Laufzeit im Browser des Clients geändert wird:
Und er stiehlt das Sitzungscookie des Administrators, wie man auf dem Server des Angreifers sehen kann:
"Da die Willkommensnachricht nach zwei Sekunden an das Administrationspanel weitergeleitet wird, wird der Administrator sich nicht bewusst sein, dass sein Sitzungscookie gestohlen wurde."
Kombinierte Angriffe: Umgehung von CSRF-Token durch Ausnutzung einer XSS-Schwachstelle
In der Beispielanwendung gibt es ein Administrationspanel (users_mgmt.php), das nur vom Site-Administrator (user admin) verwaltet wird:
Das Feld Beobachtungen ist anfällig für XSS. Jeder Benutzer kann sein Profil ändern, nachdem er sich auf seiner entsprechenden Profiländerungsseite, user_edit.php (einschließlich des Passworts), angemeldet hat.
Wenn man sich das Detail des Codes ansieht, enthält die Webseite ein Token, das mögliche Angriffe von CSRF/XSRF (Cross-Site Request Forgery). verhindert.
Wenn eine Studie zur Stärke und Zufälligkeit dieser Tokens mit dem Sequencer von BurpSuite durchgeführt wird, kann man zu dem Schluss kommen, dass es sich um ein ausreichend robustes und zuverlässiges Token handelt, das nicht leicht erraten werden kann und weit davon entfernt ist, durch Brute-Force-Angriffe angegriffen zu werden.
In 2260 analysierten Tokens wiederholte sich keines von ihnen auch nur einmal.
Dennoch, wie zuvor erwähnt, ist bekannt, dass das Beobachtungsfeld anfällig für XSS ist. Sollte dies der Fall sein, spielt die Stärke oder Zufälligkeit des verwendeten Tokens keine Rolle: Die Seite wird anfällig für CSRF sein, auch wenn sie geschützt wurde.
So könnte man diesen Injection-Angriff auf das Beobachtungsfeld missbrauchen, um ein Skript zu erstellen, das das (Anti-)CSRF-Token der aktuellen Seite liest und hilft, es zu umgehen, indem beispielsweise ein Passwortwechsel für den Administratorbenutzer durchgeführt wird (zu beachten ist, dass die Identifikation des Datensatzes durch eine ID gegeben ist, und diese ID in der Benutzerverwaltung verwendet wird, um jeden Benutzer zu bearbeiten, einschließlich des Administrators selbst (vermutlich die ID 1 der Tabelle, da der Benutzer "Hacker" die ID 6 hat).
So könnte der Benutzer "hacker" nach dem Abfangen mit Burp und dem Studium der Änderungsanfragen für jedes der Felder und der Ergebnisse beispielsweise das folgende Skript erstellen, um das aktuelle Token dynamisch aus dem DOM zu erfassen und damit das Passwort des Benutzers "admin" zu ändern und ihm das Konto zu stehlen:
So, indem Sie das Skript in das Feld Beobachtungen einfügen:
es würde erreicht werden, dass wenn der Benutzer "administrator" in die Benutzerverwaltung eintritt, das Skript unwissentlich aktiviert wird, das automatisch das Passwort ändert, sodass der Benutzer "hacker" sein Konto stehlen kann:
In diesem Moment kann der Benutzer "Hacker" mit dem Administratorkonto und dem neuen Passwort einloggen...
Abschluss
Man sollte niemals die Macht von XSS-Injektionen unterschätzen, denn sie können zu ernsthaften Problemen führen, sogar zur vollständigen Übernahme des gesamten Webservers, wenn sie gut mit anderen bestehenden Schwachstellen auf der Seite kombiniert werden.
Präventionsmaßnahmen
Um eine korrekte Minderung von XSS zu erreichen, sollten eine Reihe von bewährten Praktiken bei der Entwicklung von Webanwendungen angewendet werden:
Server- und Client-Validierung
Es reicht nicht aus, Validierungen der Felder oder Eingabeparameter des Benutzers auf der Client-Seite anzuwenden, da diese Kontrollen umgangen werden könnten (einfach indem die Validierungen auf der Client-Seite durch das Weglassen der entsprechenden Skripte vermieden werden). Es ist notwendig, eine korrekte Validierung auf der Server-Seite durchzuführen, indem die eingegebenen Daten (oder durch einen Web-Proxy abgefangenen und manipulierten Daten) validiert werden, und diejenigen, die gefährlich sein könnten oder nicht der spezifischen Funktionalität der Anwendung entsprechen, abzulehnen.
Korrekte Anwendung von Funktionen für das Escaping und die Kodierung
Es muss sichergestellt werden, dass die Kodierung der vom Benutzer eingegebenen Daten korrekt ist, bevor die Daten vom Browser interpretiert werden, indem die als "gefährlich" geltenden Zeichen mit der im verwendeten Server-Skript-Sprache vorhandenen Funktionalität, die dafür vorgesehen ist, escaped werden. Zum Beispiel gibt es in PHP Funktionen wie htmlspecialchars oder htmlentities, die bestimmte Zeichen (oder alle möglichen, im Fall der letzteren) in ihr HTML-Äquivalent umwandeln. Diese Maßnahmen sind für sich genommen nicht 100% zuverlässig, da es Umgehungsmaßnahmen gibt, aber in Kombination mit anderen und einer guten Validierung sind sie eine gute defensive Option.
Verwendung von "Whitelist"
Verwendung von Whitelists im Vergleich zur Verwendung von Listen, die die Verwendung bestimmter registrierter Zeichen oder Ausdrücke ausschließen. Es ist immer besser, die Verwendung bestimmter Informationen zu genehmigen, als die Verwendung anderer abzulehnen, für die immer ein Umgehungs- oder Ersatzsystem gefunden werden könnte. Dies sollte immer berücksichtigt werden, wenn bestimmte Regeln im WAF (Web Application Firewall) festgelegt werden.
Verwendung von Methoden zur Vermeidung der dynamischen Erstellung des DOM (Document Object Model)
Es sollten immer sichere Methoden verwendet werden, die die Eingabe von nicht validierten Daten in das DOM über JavaScript verhindern, wie z.B. setAttribute oder textContent, anstelle von innerHTML.
Einsatz von Sicherheitsköpfen
Content-Sicherheitsrichtlinie (CSP)
"Implementieren Sie mit diesem Sicherheitsheader eine Sicherheitsrichtlinie für Inhalte, um einzuschränken, welche Arten von Ressourcen in der Webanwendung ausgeführt werden können, und um die Injektion von bösartigen Skripten zu verhindern oder zu blockieren."
Content-Security-Policy: default-src 'self'; script-src 'self' http://example.com; object-src 'none'
>Der vorherige Code ermöglicht das Laden von Ressourcen ausschließlich aus der gleichen Quelle wie der Server, erlaubt nur das Laden von Skripten aus der gleichen Quelle oder von der fiktiven Seite https://example.com und blockiert vollständig das Laden von Objekten wie embed, object oder applet, die als potenzielle Angriffsvektoren dienen könnten.
X-Content-Type-Options
Angriffe basierend auf der Inhaltsanalyse (MIME-Sniffing) zu vermeiden, um auf diese Weise bösartige Skripte auszuführen:
X-Content-Type-Options: no-sniff
X-XSS-Schutz
Aktivieren Sie durch diesen Header den XSS-Filter, der von einigen Browsern verwendet wird, um die Ausführung bestimmter bösartiger Skripte zu verhindern. Nicht so robust in Bezug auf Sicherheit wie die vorherigen Header, aber eine nützliche zusätzliche Maßnahme: Der Filter wird aktiviert und wenn ein XSS-Angriff erkannt wird, blockiert der Browser die Ausführung des Skripts, anstatt zu versuchen, den Inhalt zu bereinigen (in jedem Fall sollten immer Server-seitige Bereinigungsmaßnahmen implementiert werden).
X-XSS-Protection: 1; Modus=Blockieren
X-Frame-Optionen
Durch das ausdrückliche Verbot, dass diese Seite in ein X-Frame eingebettet werden kann, wird sichergestellt, dass Clickjacking-Angriffe, die mit XSS kombiniert werden können, nicht stattfinden können, indem eine Angreiferseite eingebunden wird, die das innerhalb eines iframes injizierte bösartige Skript ausführt.
X-Frame-Options: VERWEIGERN
Cross-Origin Resource Sharing (CORS)
Durch den CORS-Header wird kontrolliert, welche Domains Anfragen an den Webserver von anderen Ursprüngen aus stellen dürfen. Richtig konfiguriert, kann er den Zugriff auf sensible Ressourcen von bösartigen Seiten (einschließlich Kombinationen von XSS mit SSRF usw.) einschränken.
Access-Control-Allow-Origin: http://example.com
Cache-Steuerung
Wenn eine falsche Konfiguration des Cache-Speichers verwendet wird, könnte dies dazu führen, dass schädliche oder sensible Inhalte unsicher gespeichert werden. Auf diese Weise kann durch die richtige Konfiguration dieses Headers verhindert werden, dass bestimmte dynamische Inhalte, die als Antwort auf bestimmte Formulare ausgeführt werden, im Cache gespeichert werden.
Cache-Control: no-store, no-cache, must-revalidate
Referrer-Policy
Obwohl dieser Header nicht direkt mit XSS in Verbindung steht, könnte ein Angreifer, wenn der Browser bestimmte Informationen als Teil des Referrer-Headers sendet, diese Informationen ausnutzen, um bestimmte sensible Daten der in diesem Header angezeigten URLs auszubeuten, die manchmal injizierbare Parameter enthalten, um beispielsweise ein XSS auszunutzen.
