Cross-Site Scripting (XSS)

Was ist Cross-Site-Scripting?

Die XSS-Schwachstelle oder Cross-Site-Scripting ist eine Schwachstelle, die das Frontend einer Webanwendung betrifft.

Diese Sicherheitslücke wurde erstmals im Januar 2000 von Microsoft benannt und ist eine der häufigsten Sicherheitslücken in Webanwendungen (Cross-Site-Scripting – Wikipedia).

Laut der OWASP-Website ist es auf zwei Dritteln des Webs vorhanden (A7:2017-Cross-Site Scripting (XSS) | OWASP).

Es ist einfach zu verstehen, wie das funktioniert: Ein Hacker injiziert einen JavaScript-Code auf der Seite einer Webanwendung, und wenn diese besucht wird, wird der Code im Browser des Benutzers ausgeführt.

 

Dies lässt sich in drei verschiedene Arten einteilen

Was sind die Arten von Cross-Site-Scripting?

Gespeicherte Schwachstelle:

Der schadhafte Inhalt wird in einer Datenbank gespeichert und erscheint bei jedem Besuch der Webanwendung.

Nicht anhaltende Sicherheitslücke:

Verwendet HTTP-Parameter (POST & GET). Der Server sendet diese nur einmal an den Browser des Benutzers.

Dokument-Objektmodell (DOM-basierte) Sicherheitslücke:

Die schädliche Nutzlast wird nicht an einen Server gesendet, sondern direkt vom Browser des Benutzers ausgeführt.

Document object model (DOM-based) vulnerability
Document object model (DOM-based) vulnerability

Bei gespeicherten Cross-Site-Scripting-Angriffen speichert der Server das Skript in der Datenbank und gibt es nur zurück, wenn der Browser eines Benutzers die Seite besucht.

Es ist für das Opfer unmöglich, einen Angriff vorauszusehen, bevor es die Seite aufgerufen hat, was die gespeicherte XSS-Schwachstelle zur wahrscheinlich gefährlichsten in der XSS-Familie macht.

Reflektierte und DOM-basierte XSS-Angriffe hingegen müssen in den Einstellungen einer Abfrage, insbesondere der URL, platziert werden.

Beide Arten von XSS-Angriffen in Links können vorhanden sein und von Hackern in E-Mails verbreitet werden. Mit ein bisschen Social Engineering können Hacker Opfer dazu bringen, auf eine URL zu klicken und das bösartige Skript wird ausgeführt.

XSS-Angriffe können auf viele Arten durchgeführt werden, von einem <script>-Tag in einem Forum, bis hin zu Code im Quellattribut eines Bildes.

Was sind Beispiele für die Auswirkungen von Cross-Site-Scripting?

Ein XSS-Angriff kann viele schlimme Folgen für Unternehmen haben.

  • Session-Hijacking: Ein Hacker kann den Browser des Opfers mit Cookies auf seinen eigenen Server umleiten und dann dessen Identität auf der Website stehlen. Wenn das Opfer ein Administrator ist, kann der Hacker alle Arten von Missetaten begehen: Datendiebstahl, Bild-/Textänderungen auf der Website, Änderung der Rolle anderer Benutzer usw.

  • Malware-Download: Der Hacker kann den Browser des Opfers dazu zwingen, eine bösartige Datei (Virus, Trojaner usw.) herunterzuladen.

 

Diese Technik kann verwendet werden, illegale Inhalte und Propagandameldungen hinzuzufügen oder die Seite komplett unbrauchbar zu machen.

Beispiel für einen Cross-Site-Scripting-Angriff auf den Webserver

1. Die grundsätzliche Verwendung eines Chats

Lassen Sie uns einen XSS-Angriff mit einem gespeicherten XSS betrachten, weil er am einfachsten zu verstehen ist, aber große Auswirkungen auf eine Webanwendung und Benutzer hat.

Nehmen wir einen einfachen Chat in einer Webanwendung ohne besonderen Schutz. Die Seite hat ein Feld, an das die Nachricht angehängt wird. Es gibt ein Formular, in das Sie etwas Text schreiben können.

Wir haben zwei Benutzer: Loris, der Hacker und Paul, das Opfer.

Das Ziel von Loris ist es, Pauls Browser auf seinen Webserver umzuleiten, um seine Cookies zu stehlen.

Wenn er auf die Schaltfläche „Posten“ klickt, wird die Nachricht an den Server gesendet.

Wenn er auf die Schaltfläche „Post“ klickt, wird die Nachricht an den Server gesendet.

Der Server speichert sie dann in der Datenbank.

Wenn Paul den Chat aktualisiert, sendet der Server die Nachricht zurück, die dann in den HTML-Code eingefügt wird.

Loris‘ Nachricht wird normal in seinem Browser angezeigt.

2. Wie erkennt man Cross-Site-Scripting?

Für seine nächste Nachricht wird Loris „Wie geht es Dir? “ in den <strong> HTML-Tag ein, der ein style-Attribut enthält, um den Text in roter Farbe darzustellen.

Wie bei der ersten Nachricht speichert der Server diese und sendet sie dann an Paul zurück.

Das <strong>-Tag wird als HTML-Code betrachtet und wie die anderen Tags in das DOM eingefügt.

Die Meldung wird im Browser des Benutzers fett und rot dargestellt.

Dieses Beispiel wurde von Loris verwendet, um zu testen, ob die Anwendung für XSS anfällig ist.

Er kann nun eine XSS-Injection mit bösartigem Inhalt durchführen.

3. Was ist ein Beispiel für einen XSS-Angriff?

Loris weiß, dass der Chat anfällig für einen gespeicherten XSS-Angriff ist und beschließt, Pauls Cookies zu stehlen.

Die Sprache JavaScript hat zwei Elemente, die ihm helfen, dieses Ziel zu erreichen:

  • location, die verwendet werden kann, um einen Browser auf eine andere URL umzuleiten.
  • cookie, das Cookies eines Benutzers auf der aktuellen Website enthält.

Mit dem obigen Code kann Loris den Browser von Paul und seine Cookies auf seine eigene Website umleiten.

Alles, was er jetzt tun muss, ist, sich auf seiner Website einzuloggen, um Pauls Cookies zu erhalten.

Dieser Fall stellt ein einfaches Beispiel für eine XSS-Injektion dar. Der Angreifer entscheidet es, mit welcher Technik sein Ziel erreicht werden soll (Verschlüsselung, Verschleierung des Codes usw.).

OWASP-Best-Practice-Beispiel

Das Open Web Application Security Project (OWASP) stellt eine Liste von Regeln zur Verfügung, die Sie zum Schutz Ihrer Webanwendungen anwenden können:

  • Das Umgehen von HTML-, CSS- und JavaScript-Zeichen ist die wahrscheinlich sinnvollste Regel, die man anwenden kann. Nichtüberprüfung von Benutzereingaben in ihrem Code führt dazu, dass diese bösartige Inhalte enthalten können.

Um diese Regel zu implementieren, können Sie Funktionen verwenden, die in den verschiedenen Programmiersprachen zur Verfügung stehen oder Accountants verwenden, die für die Bereinigung der Benutzereingaben vorgesehen sind.

Die meisten modernen Frameworks wie Angular, React oder Vue implementieren diese Funktion nativ.

Die Integration eines Content-Security-Policy-Headers in die HTTP-Daten ist also auch eine gute Möglichkeit, die Browser der Benutzer zu schützen, da sie nur Ressourcen des Servers verwenden können. Beachten Sie, dass die Inhaltssicherheitsrichtlinie gut konfiguriert sein muss, da sie zu anderen Sicherheitslücken führen kann.

  • Ein weiterer Header und die X-XSS-Protection, die automatisch einige XSS-Angriffe filtert, ist standardmäßig aktiviert.

 

Alle Empfehlungen der OWASP können Sie hier nachlesen: Cross Site Scripting Prevention – OWASP Cheat Sheet Series

So schützen Sie Ihre Webanwendung vor XSS mit R&S®Cloud Protector

Um eine Webanwendung vor XSS-Schwachstellen zu schützen, kann R&S®Cloud Protector:

Die Blacklisting-Strategie auf allen Ebenen des Schutzes verwenden:

Sobald R&S®Cloud Protector ein bösartiges Muster erkennt, das normalerweise zur Durchführung eines Cross-Site-Scripting-Angriffs verwendet wird, wird die Anfrage blockiert und umgeleitet.

Scoring List wird auf der Schutzstufe Erweitert und Hoch aktiviert:

R&S®Cloud Protector analysiert die Anfrage und erhöht eine Punktzahl, wenn sie einem bösartigen Muster wie einem HTML-Tag oder einer JavaScript-Funktion entspricht.

Am Ende der Analyse, wenn die Punktzahl über dem definierten Grenzwert liegt, wird die Eingabe als XSS-Angriff betrachtet, sodass die Anfrage blockiert und umgeleitet wird.

Die Scoring-Liste ist vorteilhaft, wenn Sie False-Positive Ergebnisse vermeiden wollen.

Fordern Sie Ihre 14-tägige gratis Testversion an

In nur 60 Sekunden Websites und Anwendungen schützen Worauf warten Sie?