Ein Angreifer fügt beim Cross Site Scripting (XSS) eine JavaScript-Datei in eine vertrauenswürdige Webseite ein, welche die Opfer aufrufen. Wenn die Opfer die Webseite aufrufen, infiziert das Script den Computer des Opfers automatisch.
Beispiel1: Der Angreifer sendet dem Opfer via Chat den Inhalt eine JavaScript-Datei. Falls der Chat gegen Cross Site Scripting nicht geschützt ist, erhält der Empfänger nicht das Code-Snippet, sondern muss die Schadeffekte des Skripts ertragen. Malware kann verschiedene Effekte verursachen.
Beispiel 2: Wenn der Angreifer in ein ungeschütztes Forum seine JavaScript-Datei zu seinem Beitrag hinzufügt, dann führt sich der JavaScript-Code bei jedem Benutzer des Forums aus.
Einordnung und verwundbare Anwendungen
Das“Cross-Site-Scripting“ (XSS) ist ein webseitenübergreifendes Skripting wie z. B. Refleted XSS und DOM-Based. Diese Art von Hacking kann man in die HTML-Injection einordnen. Oft finden die Angriffe mit der Nutzung von JavaScript statt.
XSS ist eine Gefahr für alle Webseiten, die in irendeiner Form Daten verarbeiten und nicht nur als reines statisches Dokument anzeigen. Dazu gehören PHP, Python oder JavaScript Web Apps.
Kriminelle haben mit JavaScript Zugriff auf Deine Kamera, Mikrofon, Dateisystem und GPS-Standort ansteuern. Die HTML 6 API ermöglicht diesen Zugriff mit JavaScript.
Das Motiv hinter XSS-Angriffe
Kriminelle nutzen XSS, um Black-Hat-Backlinks zu erstellen.
Ungeschützte Kommentarfelder und Formulare missbraucht das Script, um diese zu füllen und abzusenden. Der generierte Backlink hilft dem Angreifer dabei, seine Webseiten in Google höher ranken zu lassen.
Die Suchmaschine Google bewertet diese Technik der Backlink-Setzung als negativ und rankt die Webseite herunter. XSS eine Back-Hat-Methode, um Backlinks zu setzen.
Wie funktioniert XSS
XSS gibt es in drei verschiedenen Arten:
Reflektierend: Bei dem reflektierenden XSS sendet der Angreifer eine Mail zu dem Opfer und der Klick auf den Link startet den Schadcode automatisch. Diese Form ist eine Client-seitige Implementierung.
Persistent: Diese XSS-Form liegt auf der Seite des Servers. Der Kriminelle speichert das Script in eine SQL-Datenbank durch Formular- oder Kommentar-Felder.
Lokal / DOM-basiert: Für diese Methode muss der Hacker keine Einfügungen auf einer Webseite machen. Über einen gefälschten GET-Parameter in die URL fügt der Hacker JavaScript ein. Wenn der Kriminelle die URL kürzt, erkennt der Nutzer nicht, dass JavaScript im Spiel sein kann.
Lokales XSS ist verherrend
Verwundbare Kommentare und Formulare
Cross Site Scripting / XSS kann der Angreifer nicht nur in <script> Tags schreiben, sondern der Code führt sich in den folgenden Tags aus:
body: HTML-Haupttext
input: Eingabefelder
link: Ressourcen
href: Tags
script: JavaScript
img: Bilder
…
Mit dem Aufruf der Webseite laden die DOM-Objekte mit den verlinkten Ressourcen.
ATTACKE! – XSS auf Webseiten
Der Hacker kann beispielsweise in ein Kommentarfeld eines Blogs eine Script-Datei einfügen, die in der SQL-Tabelle der Webseite abgespeichert wird. Die erstellten Kommentare zeigt die Webseite unterhalb des Posts kompiliert an.
Kommentarfelder sind einInput für Cross Site Scripting Beispiel + XSS Tutorial
Im Browser des Seitenbesuchers führt sich das Schad-JavaScript aus und kann aktiv werden.
Und WordPress ist aber schon schlauer:
Sicherung: PHP- und Encoding-Firewall gegen XSS
Wenn der Browser-Nutzer sich gegen XSS schützen möchte, müsste er JavaScript und alle Flash-Sprachen standardmäßig deaktivieren. Diese Strategie schützt 100 % vor XSS-Angriffen.
Aber:
Im Web 3.0 sind Cookies, Sessions und Logs eine Selbstverständlichkeit. Der Nutzer müsste bei Deaktivierung von JavaScript auf vieles verzichten: Weder in Amazon kann der vorsichtige Nutzer etwas kaufen, noch kann er auf Netflix eine Serie schauen. Viele Webseiten zeigen sich nicht mehr ohne JavaScript an.
Single Page Applications basieren auf JavaScript. Diese Sprache ist eine der beliebtesten überhaupt im Web, weil die meisten Programmierer JavaScript programmieren können.
Das No-Script Plugin zwingt Firefox dazu, allen JavaScript-Codes zu ignorieren.
Bei XSS Attacken sind nicht die Nutzer in der Pflicht, sondern die Webseitenbetreiber. Sie müssen dafür Sorge tragen, dass die Kriminellen nicht in ihre Eingabefelder und Uplodas JavaScript einbetten können.
Um spammende Bots von Beginn an auszuschließen, solltest Du ein PHP-generiertes geheimes Feld Deinen HTML-Formularen hinzufügen. Die Bots sind so programmiert, dass Sie für ein bekanntes Standard-Plugin wie Contact-Form 7 alle Felder automatisch füllen und absenden. Enthält das Formular spezielle und unbekannte Felder, dann scheitern die meisten Bots.
Extra-Sicherheit: Bollwerk gegen XSS
Um XSS zu verhindern, sollte der Webprogrammierer alle PHP-Skripte überprüfen, ob …
… die Eingabe ungewöhnlich lange ist.
… JavaScript typische Syntax erscheint.
… die Eingabe URLs beinhaltet.
… ein Skrpt eine externe Web-Ressource lädt.
PHP stellt einige Funktionen zu Verfügung, die vermeiden, dass Schadcode in Deine Datenbanken gerät. Mit PHP kannst Du einfach mit strip_tags() alle Tags löschen. Alle HTML-Sonderzeichen wandelt die PHP-Funktion htmlentities() um in einen UTF-8 Texte, der als gedruckten Code im Browser erscheint.
htmlspecialchars($gefaerlicherString, ENT_QUOTES, 'UTF-8');
oder
filter_input($unsecureStuff, 'input', FILTER_SANITIZE_SPECIAL_CHARS)
API Nutzung mit JavaScript – Cross Site Script verhindern
Cross-Site Scripting (XSS) ist eine häufige Sicherheitslücke, die auftreten kann, wenn eine Webanwendung Benutzereingaben verarbeitet und sie ohne ausreichende Validierung oder Kodierung in den Browser zurückgibt. Bei der Nutzung von APIs in Verbindung mit JavaScript gibt es spezifische Maßnahmen, um XSS effektiv zu vermeiden.
Zunächst ist es wichtig, Benutzereingaben stets als potenziell gefährlich zu betrachten. Alle Daten, die von einer API empfangen werden, sollten validiert und desinfiziert werden, bevor sie in die Anwendung eingebunden werden. Hierzu gehört beispielsweise die Verwendung von serverseitiger Validierung, um sicherzustellen, dass nur erwartete und zulässige Daten verarbeitet werden. Auf der Client-Seite sollten keine ungesicherten Daten direkt in die DOM-Struktur eingebettet werden. Stattdessen sollte man DOM-APIs wie textContent oder innerText verwenden, um Inhalte zu setzen, anstatt riskante Methoden wie innerHTML, die anfällig für XSS sind.
Wenn eine API dynamische Daten liefert, die im HTML- oder JavaScript-Code verwendet werden, ist es ratsam, diese Daten vor der Ausgabe zu kodieren. Eine robuste Output-Encoding-Bibliothek, wie sie in vielen Frameworks enthalten ist, kann hierbei helfen. Zudem sollten alle Inhalte, die in Attributen, URLs oder Skripten eingebunden werden, entsprechend ihrem Kontext kodiert werden.
Ein weiterer wichtiger Schutzmechanismus besteht darin, die Verwendung von unsicheren Funktionen zu vermeiden, die JavaScript-Code direkt ausführen, wie beispielsweise eval(), setTimeout() oder new Function(). Stattdessen sollten sichere Alternativen genutzt werden, um solche Risiken zu minimieren.
Bei der Arbeit mit APIs ist zudem darauf zu achten, dass die API keine schädlichen oder unerwarteten Inhalte zurückgibt. Hierzu kann es hilfreich sein, Sicherheitsheader wie Content-Security-Policy (CSP) zu implementieren. CSP hilft, die Ausführung von nicht vertrauenswürdigem Code zu blockieren, indem es nur den erlaubten Quellen gestattet, Skripte oder Inhalte zu laden.
Zusammenfassend lässt sich sagen, dass die Vermeidung von XSS bei der API-Nutzung und in JavaScript eine Kombination aus Eingabesanitierung, kontextbezogener Kodierung, der Vermeidung riskanter Funktionen und der Implementierung sicherer Header erfordert. Durch diese Maßnahmen wird das Risiko, dass bösartiger Code in der Anwendung ausgeführt wird, deutlich reduziert.
Wie kann ich auf Fehler automatisch prüfen?
Es gibt zahlreiche Tools, die bei der automatisierten Überprüfung von Webanwendungen und APIs auf Sicherheitslücken wie Cross-Site Scripting (XSS) hilfreich sind. Diese Tools können dazu beitragen, Schwachstellen frühzeitig zu erkennen und zu beheben. Hier sind einige der bekanntesten Tools:
1. Web Vulnerability Scanners
OWASP ZAP (Zed Attack Proxy) Ein Open-Source-Tool von OWASP, das Schwachstellen wie XSS, SQL-Injection und mehr erkennt. Es bietet eine einfache Integration in CI/CD-Pipelines und ist ideal für die automatische Sicherheitsprüfung.
Burp Suite (Community und Professional Edition) Ein leistungsstarkes Tool zur Sicherheitsprüfung von Webanwendungen. Die Professional Edition bietet automatisierte Schwachstellenscans, während die Community Edition manuelle Tests unterstützt.
Acunetix Ein kommerzieller Webscanner, der speziell auf Schwachstellen wie XSS, SQL-Injection und CSRF (Cross-Site Request Forgery) abzielt. Es bietet umfassende Berichte und Integrationsmöglichkeiten.
Diese Tools analysieren den Quellcode der Anwendung, um Schwachstellen wie XSS frühzeitig zu identifizieren:
SonarQube Unterstützt viele Programmiersprachen und bietet Plugins für die Analyse von Sicherheitsproblemen, einschließlich XSS in JavaScript oder HTML.
Postman Obwohl Postman primär ein API-Test-Tool ist, kann es durch Automatisierung und Skripting Sicherheitsprüfungen bei API-Nutzung unterstützen. Mithilfe von Plugins oder eigenen Skripten lassen sich Sicherheitstests integrieren.
Google Chrome DevTools Chrome bietet ein integriertes Toolset, das helfen kann, Schwachstellen durch Debugging und Analyse der DOM-Manipulation zu identifizieren.
Verwendung: Überprüfen Sie die Verwendung von eval(), innerHTML und anderen riskanten Funktionen im JavaScript-Profiler.
Empfehlung:
Für eine umfassende Sicherheitsstrategie empfiehlt sich eine Kombination aus statischen (SAST) und dynamischen (DAST) Scans sowie die regelmäßige Nutzung von Vulnerability Scannern wie OWASP ZAP oder Burp Suite. Ergänzend sollte die Sicherheitsanalyse in den Entwicklungsprozess (CI/CD-Pipeline) integriert werden, um Schwachstellen frühzeitig zu beheben.
Credits
Icons made by Gregor Cresnar from www.flaticon.com is licensed by CC 3.0 BY – Icons made by dDara from www.flaticon.com is licensed by CC 3.0 BY – Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY -Icons made by Those Icons from www.flaticon.com is licensed by CC 3.0 BY – Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY – Icons made by srip from www.flaticon.com is licensed by CC 3.0 BY
Lass uns wissen, was du denkst! War dieses Tutorial /Beitrag hilfreich, oder hast du noch brennende Fragen? Schreibe einen Kommentar und werde Teil unserer wachsenden Community. Teile Deine Erfolge, Herausforderungen und Tipps – gemeinsam schaffen wir Großes im Bereich Security und Coding!
