Sichere Programmierung von Web-Anwendungen - Cross-Site Scripting (XSS)
Zahlreiche erfolgreiche Angriffe auf bekannte Web-Anwendungen finden wöchentlich Einzug in einschlägige Medien. Grund genug bei der Entwicklung eigener Anwendung - egal ob zur rein internen Nutzung oder mit öffentlichem Zugang - sich mit den Hintergründen der "Web Application Security" zu beschäftigen.
Dies ist ein Auszug aus dem Buch "Sicherheit von Web-Anwendungen: Für Software-Entwickler und Software-Projektleiter", auch als eBook erhältlich
Es ist ebenfalls ein zugehöriger Online-Kurs erschienen: Onlinekurs Sicherheit von Web-Anwendungen, auch verfügbar auf Udemy, und als HTML5/SCORM/mit Audiokommentar auf Anfrage
Beschreibung
Cross-Site-Scripting (XSS) ist eine der am häufigsten vorkommenden Sicherheitslücken in Web-Anwendungen. Sie wird häufig unterschätzt, kann jedoch sehr viel Schaden anrichten und ebenfalls Folgeangriffe auslösen (z.B. Session-Hijacking). Die Ursache für XSS-Lücken ist ein fehlendes oder lückenhaftes Output-Encoding (entsprechend für HTML, JavaScript, ...). Eine falsche Annahme über die Quelldaten, welche von der Web-Anwendung ausgegeben werden sollen, kann manchmal aber auch auf falsche Input-Validierung bzw. -Filterung zurückgeführt werden.
Liegt ein unzureichendes Output-Encoding vor, kann ein Angreifer eigenen Code in die Web-Anwendung einbringen, der bei den Nutzern zur Ausführung kommt. Hierbei kann es sich um reine HTML-Kommandos handeln oder JavaScript-Code. Gelingt dies, stehen dem Hacker alle Nutzungsmöglichkeiten im Kontext des Nutzers der Web-Anwendung zur Verfügung.
Um seinen Code zur Ausführung zu bringen, muss der Angreifer seine Opfer dazu bringen, manipulierte URLs aufzurufen. Dies kann einerseits durch direkte Kanäle (z.B. bei Einbettung in gemeinsam zugänglichen Bereichen der Web-Anwendung) oder andere Kanäle wie Drittseiten oder Phishing-Mails erfolgen. Man unterscheidet die folgenden Arten von Cross-Site-Scripting (vgl. Kapitel "Hacking-Anatomie"):
-
Persistent:
Dem Angreifer gelingt die Ablage von eigenem Code - vorbei an Input-Filtern und Output-Encoding - innerhalb der Web-Anwendung. Ein Beispiel ist eine Gästebuchfunktion, dessen Einträge für alle Besucher sichtbar sind. Selbstverständlich wären bei solch einem Angriff auch nicht-eingeloggte Nutzer betroffen. Beispiel: Dem Angreifer gelingt die Ablage von
unter einer bestimmten URL, etwa
<script>alert('XSS')</script>Bei jedem Besucher dieses Eintrages innerhalb der Web-Anwendung oder auch beim Klick auf den Link wird der Schadcode des Angreifers ausgeführt.https://example.com/guestbook?entry=99123 -
Reflektiert:
Die Web-Anwendung gibt den Inhalt von URL-Parametern direkt im HTML der Ausgabe aus. Dem Angreifer gelingt die Eingabe von eigenem Code - vorbei an Input-Filtern und Output-Encoding. Ein klassisches Beispiel sind Suchfunktionen. Beispielsweise könnte folgender Suchparameter anfällig sein:
Der Angriffscode
https://example.com/search?query=suchwortwürde dann eingebettet in die URL so aussehen:<script>alert('XSS')</script>Bei Aufruf des Links, der ja von der dem Nutzer bekannten Web-Anwendung stammt, wird der Schadcode ausgeführt.https://example.com/search?query=%3Cscript%3Ealert(%27XSS%27)%3C/script%3E - DOM-basiert: Die DOM-basierte Variante funktioniert sehr ähnlich wie die reflektierte Variante. Hierbei wird jedoch der schlecht gesicherte URL-Parameter nicht von der Web-Anwendung selbst, sondern erst clientseitig - beispielsweise durch JavaScript - ausgewertet. Wieder entsteht die gleiche, manipulierte URL. Der fehlerhafte Code befindet sich aber nicht im Serverteil der Web-Anwendung, sondern im ausgelieferten JavaScript.
Sichere Programmierung:
Die Verhinderung von XSS-Lücken ist einfach und elementar: Encoding aller für den jeweiligen Kontext relevanter Steuerzeichen - meist HTML und JavaScript (aber ggf. auch XML, JSON und - sofern verwendet - Plugins). Es gibt für viele Programmierumgebungen mindestens externe Bibliotheken, die ein entsprechendes Encoding vornehmen, da es sich um ein so häufiges Problem handelt. Das Encoding kann aber durchaus auch selbst realisiert werden.
Essentiell ist die klare - am besten zentrale - Erfassung aller Codestellen, die Nutzerdaten verarbeiten.
→ Das beste Encoding nutzt nichts, wenn es nicht an allen relevanten Stellen Anwendung findet!
Die wichtigsten Encoding-Regeln zum Umwandeln von Zeichen innerhalb von Nutzereingaben:
- & in &
- " in "
- < in <
- > in >
- ' in '
Schlagworte
Sicherheitslücke, XSS, Cross-Site-Scripting, Secure Code, Secure Coding, OWASP, Sichere Programmierung, Web-/Anwendungssicherheit, Secure Programming, Web Application Security, Softwarentwicklung, IT-Securitymanagement, Security Awareness
Kategorien: IT-Sicherheit Hintergrundartikel Programmieren/Java
Kommentare
Eigenen Kommentar hinzufügen
Teilen / Weiterempfehlen
Wenn Sie diese Seite gut finden, teilen Sie es doch ihren Kontakten mit:
reddit
Digg
StumbleUpon
XING
WhatsApp
Telegram