Webanwendungssicherheit

Die Sicherheit von Webanwendungen befasst sich mit den spezifischen Schwachstellen von Websoftware – Injection, Cross-Site-Scripting, fehlerhafte Authentifizierung und Zugriffssteuerung – die zu den häufigsten und wirkungsvollsten in modernen Systemen gehören.

Definition

Webanwendungssicherheit ist die Praxis, webbasierte Software und ihre Benutzer vor Angriffen zu schützen, die die Handhabung von Eingaben, Sitzungen, Authentifizierung und Zugriffssteuerung der Anwendung sowie Schwachstellen im Browsersicherheitsmodell ausnutzen.

Scope

Dieses Thema behandelt das Bedrohungsmodell von Webanwendungen (nicht vertrauenswürdiger Client, feindliches Netzwerk, Multi-Tenant-Server) und seine charakteristischen Schwachstellenklassen: Injection (SQL und Befehl), Cross-Site-Scripting, Cross-Site-Request-Forgery, fehlerhafte Zugriffssteuerung und Authentifizierung sowie unsichere Deserialisierung. Es behandelt das Browsersicherheitsmodell (Same-Origin-Policy, Content Security Policy) und Standardabwehrmechanismen. Ausgeschlossen sind Low-Level-Speicherausnutzung und allgemeine sichere Entwicklungsprozesse, die in verwandten Themen behandelt werden.

Core questions

• Warum führt das Mischen von nicht vertrauenswürdigen Eingaben mit Code oder Abfragen zu Injection-Schwachstellen?
• Wie greifen Cross-Site-Scripting und Cross-Site-Request-Forgery die Benutzer einer Website an?
• Wie schränkt die Same-Origin-Policy des Browsers ein, was Webcode tun kann?
• Wie werden Authentifizierung, Sitzungen und Zugriffssteuerung in Webanwendungen häufig fehlerhaft implementiert?
• Welche Standardabwehrmechanismen verhindern die häufigsten Web-Schwachstellen?

Key concepts

• SQL- und Befehls-Injection
• Cross-Site-Scripting (XSS)
• Cross-Site-Request-Forgery (CSRF)
• fehlerhafte Zugriffssteuerung
• fehlerhafte Authentifizierung und Sitzungsverwaltung
• Same-Origin-Policy
• Content Security Policy
• parametrisierte Abfragen
• OWASP Top Ten

Key theories

Injection und die Code-/Daten-Verwechslung

Injection-Schwachstellen (SQL-Injection, Command-Injection) entstehen, wenn nicht vertrauenswürdige Eingaben als Code interpretiert werden; die Abwehr besteht darin, Daten und Code getrennt zu halten, hauptsächlich durch parametrisierte Abfragen und strikte Ausgabekodierung.

Browsersicherheitsmodell und clientseitige Angriffe

Die Same-Origin-Policy isoliert Inhalte unterschiedlicher Herkunft, aber Cross-Site-Scripting injiziert Angreiferskripte in eine vertrauenswürdige Seite, und Cross-Site-Request-Forgery missbraucht die authentifizierte Sitzung eines Benutzers; Abwehrmechanismen umfassen Ausgabekodierung, Content Security Policy und Anti-CSRF-Tokens.

Mechanisms

SQL-Injection tritt auf, wenn Benutzereingaben in eine Abfrage konkateniert werden, wodurch ein Angreifer deren Logik ändern kann; parametrisierte Abfragen beheben dies, indem sie Eingaben als Daten binden. Cross-Site-Scripting injiziert Skripte in eine Seite, die dann von den Browsern anderer Benutzer ausgeführt werden, was durch kontextsensitive Ausgabekodierung und Content Security Policy gemildert wird. Cross-Site-Request-Forgery verleitet einen authentifizierten Browser dazu, unerwünschte Anfragen zu stellen, was mit Anti-CSRF-Tokens und SameSite-Cookies abgewehrt wird. Fehler bei der Zugriffssteuerung entstehen, wenn der Server die Autorisierung bei jeder Anfrage nicht überprüft.

Clinical relevance

Schwachstellen in Webanwendungen verursachen viele der größten Datenlecks: SQL-Injection und fehlerhafte Zugriffssteuerung haben Milliarden von Datensätzen offengelegt, und Cross-Site-Scripting kompromittiert routinemäßig Benutzerkonten. Da fast alle Dienste eine Weboberfläche haben, wirkt sich die Websicherheit direkt auf E-Commerce, Bankwesen, Gesundheitsportale und Regierungssysteme aus und ist ein Anker für Penetrationstests, Bug-Bounty-Programme und Compliance-Regime wie PCI-DSS.

Evidence & guidelines

Die OWASP Top Ten ist die De-facto-Referenz für verbreitete Webrisiken, ergänzt durch den OWASP Application Security Verification Standard (ASVS) und Cheat Sheets. Browserseitig durchgesetzte Abwehrmechanismen (Content Security Policy, SameSite-Cookies, Subresource Integrity) sind vom W3C und WHATWG standardisiert. Compliance-Frameworks wie PCI-DSS schreiben Web-Sicherheitskontrollen für Systeme vor, die Zahlungsdaten verarbeiten.

History

Die Sicherheit von Webanwendungen entwickelte sich mit dem dynamischen Web der späten 1990er und 2000er Jahre, als Datenbanken und Benutzereingaben zu Injection- und Skripting-Schwachstellen führten. Die OWASP Top Ten (erstmals 2003 veröffentlicht) standardisierte das Bewusstsein für die kritischsten Risiken. Browserseitige Abwehrmechanismen entwickelten sich über die Same-Origin-Policy und später die Content Security Policy, während wegweisende Sicherheitsverletzungen wiederholt die realen Kosten von SQL-Injection und fehlerhafter Zugriffssteuerung aufzeigten.

Key figures

• Dafydd Stuttard
• Ross Anderson
• Jeremiah Grossman
• Michal Zalewski

Seminal works

• stuttard2011
• owasp2021
• anderson2020

Frequently asked questions

Was ist die effektivste Einzelmaßnahme gegen SQL-Injection?

Die Verwendung von parametrisierten Abfragen (Prepared Statements), die die SQL-Struktur und die vom Benutzer bereitgestellten Werte getrennt senden, sodass Eingaben niemals als Teil der Abfrage interpretiert werden können. Dies hält Code und Daten getrennt und neutralisiert die Angriffsklasse.

Wie unterscheidet sich Cross-Site-Scripting von SQL-Injection?

Beide resultieren aus nicht vertrauenswürdigen Eingaben, aber SQL-Injection zielt auf die Datenbank des Servers ab, während Cross-Site-Scripting bösartige Skripte injiziert, die in den Browsern anderer Benutzer innerhalb der vertrauenswürdigen Website ausgeführt werden. SQLi stiehlt oder ändert Serverdaten; XSS kapert Benutzersitzungen und -aktionen.