Sicherheit von Webanwendungen

Grundidee und Zuständigkeiten

Die Sicherheit von Webanwendungen ist ein zentraler Teil ihrer Entwicklung. Webanwendungen verarbeiten Daten über das Internet, arbeiten oft mit Benutzerkonten und verbinden Browser, Server, Datenbanken und weitere Systeme. Deshalb müssen sie so geplant und umgesetzt werden, dass Angriffe möglichst verhindert, erkannt oder begrenzt werden.

Ein Ebenenmodell hilft dabei, die Zuständigkeiten für Sicherheitsaufgaben zu ordnen. Es unterscheidet fünf Ebenen: Semantik, Logik, Implementierung, Technik und System sowie die Ebene „Netzwerk und Host“. Dadurch wird klarer, wer für welche Teilaufgabe bei Sicherheitskonzeption und Realisierung verantwortlich ist.

Wichtige Angriffe

Bei einer SQL-Injection schickt ein Angreifer Anfrage-Parameter mit SQL-Steuerzeichen an den Webserver. Wenn die Anwendung diese Zeichen nicht abfängt und sie in eine SQL-Abfrage übernimmt, können Daten ausgelesen oder verändert werden, die sonst nicht zugänglich wären.

Cross-Site-Scripting (XSS) bezeichnet Angriffe, bei denen Code oder manipulierte Informationen eingeschleust werden. Beim clientseitigen XSS gelangt zum Beispiel JavaScript in eine Webseite und wird im Browser des Opfers ausgeführt. Serverseitiges XSS bedeutet, dass manipulierte Informationen in eine auf dem Server ausgeführte Skriptsprache gelangen, sodass etwa eine nicht vorgesehene Datei ausgeführt wird.

Session Hijacking nutzt aus, dass HTTP verbindungslos ist und Webanwendungen Benutzer über eine Session-ID erkennen. Diese Session-ID kann über Basic/Digest Authentication, Cookie, URL-Rewriting oder HTTP-Form-Parameter übertragen werden. Erlangt ein Angreifer sie, kann er die Identität des Opfers vortäuschen. Bei Cross-Site-Request-Forgery wird dagegen eine bestehende Session im Browser des Benutzers ausgenutzt, ohne dass der Angreifer die Session-ID kennen muss.

Weitere Angriffe sind Directory Traversal, bei dem manipulierte Pfadangaben wie „../../../Config.sys“ verwendet werden, E-Mail-Injection über Kontaktformulare, Man-in-the-Middle-Angriffe zwischen Benutzer und Server sowie Man-in-the-Browser-Angriffe, bei denen Webseiten direkt im Browser verändert und Transaktionen unbemerkt ausgeführt werden können. Denial-of-Service-Angriffe versuchen, Server durch viele Anfragen lahmzulegen; bei Angriffen von vielen Computern spricht man von Distributed Denial of Service (DDoS). Phishing ist keine Sicherheitslücke der Webanwendung selbst, sondern Social Hacking: Opfer werden auf gefälschte Webseiten gelockt, um Zugangsdaten wie PIN und TAN einzugeben.

Eingaben prüfen und begrenzen

Die wichtigste Schutzmaßnahme ist Data Validation, also die Prüfung von Eingabe- und Ausgabedaten. Nicht nur Daten aus Formularen, sondern der gesamte Datenfluss zwischen Benutzer, Anwendung, Subsystemen und Ausgabe muss betrachtet werden. Im Idealfall prüft ein zentrales Data-Validation-Modul alle Input- und Output-Daten.

Wenn möglich, ist Whitelisting besser als Blacklisting. Beim Blacklisting werden verbotene Muster herausgefiltert, alles andere wird zugelassen. Beim Whitelisting sind nur ausdrücklich erlaubte Werte gültig, alle anderen werden abgelehnt. Das ist sicherer, wenn die erlaubten Eingaben klar definierbar sind, weil neue oder übersehene gefährliche Muster automatisch blockiert werden.

Ungültige Eingaben müssen je nach Ursache unterschiedlich behandelt werden. Bei normalen Fehleingaben soll die Anwendung benutzerfreundlich reagieren und nur notwendige Informationen preisgeben. Bei bewusster Manipulation kann die Verarbeitung abgebrochen, zur Hauptseite zurückgeleitet, eine Warnung ausgegeben oder eine bestehende Session ungültig gemacht werden. Fehler sollten nicht ungefiltert ausgegeben werden, besonders keine SQL-Fehlermeldungen. Auch ein Server Error 500 oder eine irreführende Wartungsmeldung sind problematisch. Von Versuchen, fehlerhafte Eingaben automatisch zu korrigieren, wird abgeraten.

Gegen SQL-Injection helfen Prepared Statements, weil SQL-Abfragen nicht dynamisch aus Benutzereingaben zusammengesetzt werden müssen. Stored Procedures haben ähnliche Eigenschaften, schützen aber nicht automatisch, wenn ungeprüfte Parameter übergeben werden. Weitere Regeln sind: Eingaben serverseitig prüfen, auch Namen von Formular-Variablen validieren, die Länge bzw. Größe von Eingabedaten begrenzen und bei Bedarf Escape-Funktionen verwenden. Clientseitige Prüfungen mit JavaScript können die Bedienung verbessern, ersetzen aber nie die Prüfung auf dem Server.

Sessions, Rechte und Weiterleitungen

Session Management gilt als besonders problematischer Bereich. Eine Session-ID darf nicht aus bekannten oder leicht erratbaren Daten wie IP-Adresse, Uhrzeit, Prozess-ID, Geburtsdatum oder E-Mail-Adresse abgeleitet werden. Sie braucht hohe Zufälligkeit, ausreichende Länge gegen Brute-Force-Angriffe und soll bei entsprechendem Schutzbedarf nur über sichere Kanäle übertragen werden. Eine Anwendung, die SSL benötigt, darf die Session-ID niemals versehentlich unverschlüsselt übertragen. Sessions sollen außerdem nur so lange gültig sein, wie es für den Zweck nötig ist.

Zusätzliche Parameter können an eine Session gebunden werden, etwa die IP-Adresse des Clients. Das kann Schutz bieten, verursacht aber Probleme bei Proxys, wechselnden Routern oder Reverse-Proxys, bei denen die echte Benutzer-IP nicht zuverlässig ankommt. In Intranets kann diese Maßnahme eher einsetzbar sein.

Session Riding soll durch einen SessionCode oder andere Maßnahmen verhindert werden. Als besonders sichere Form wird Dialogtracking beschrieben: Für jeden Dialogschritt wird ein Token erzeugt, in Links eingebaut, beim Request geprüft und anschließend aus der Liste gültiger Token gestrichen. Ein erneuter Aufruf desselben Links ist dann nicht mehr möglich.

Privilege Escalation bedeutet, dass ein angemeldeter Benutzer unberechtigt höhere Rechte nutzt. Im Beispiel einer Bestellverwaltung darf ein Benutzer nur eigene Bestellungen sehen. Übergibt die Anwendung aber nur eine Bestell-ID als Parameter und prüft nicht mehr, ob diese Bestellung dem Benutzer gehört oder ob der Benutzer Administrator ist, entsteht eine Schwachstelle. Die Prüfung sollte in der Business-Logik, etwa im Modell einer MVC-Struktur, verankert werden.

Weiterleitungen müssen kontrolliert werden. Bekannte Ziele sollten nur über erlaubte Einträge, zum Beispiel über einen serverseitigen Datenbankindex, zugelassen werden. Externe Weiterleitungen können über eine Hinweisseite geführt werden, damit Benutzer den Link prüfen. Referrer-Tests können zusätzlich helfen, sind aber nicht immer zuverlässig. Lokale Weiterleitungen sollten nur relative Pfade annehmen und die Domain statisch ergänzen.

Benutzer, Werkzeuge und Recht

Benutzerkennungen sollten als nicht-öffentliche Informationen behandelt werden. E-Mail-Adressen oder leicht ableitbare Muster wie vorname.nachname sind zu vermeiden. Anwendungen sollen außerdem keine Hinweise geben, ob eine Benutzerkennung existiert. Eine „Passwort vergessen“-Funktion sollte daher neutral antworten, etwa dass eine E-Mail gesendet wurde, falls die UserID korrekt war.

Sichere Passwörter entstehen nicht allein durch freie Wahl der Benutzer. Das System soll Regeln vorgeben und prüfen. Vermieden werden sollen einfache Wörterbuchwörter, persönliche Angaben wie Name oder Geburtstag und einfache Zahlenkombinationen. Empfohlen werden Kombinationen aus Wörtern, Sonderzeichen, Groß- und Kleinschreibung sowie Zahlen; die Länge ist entscheidend.

SSL/TLS/HTTPS schützt vertrauliche Daten wie Passwörter oder Bankdaten durch Verschlüsselung zwischen Browser und Server. Das SSL-Server-Zertifikat stellt außerdem sicher, dass der Hostname authentisch ist; unter Ausschluss von DNS-Manipulation garantiert es auch die Echtheit des Hosts, sofern keine Frames benutzt werden.

Hilfsprogramme können die Sicherheit unterstützen. Web Shields oder Web Application Firewalls filtern den Datenstrom zwischen Browser und Webanwendung, können aber nicht alle Angriffe erkennen und sollen Sicherheitsprobleme nicht ersetzen, sondern nur zusätzlich absichern. Web Scanner dienen Penetrationstests. Sie crawlen und analysieren Anwendungen, testen Eingaben und erzeugen Reports, können aber fehlendes Fachwissen nicht ausgleichen.

Strafrechtlich beschreibt der Artikel die Situation in Deutschland. Rechtswidriges Verändern, Löschen, Unterdrücken oder Unbrauchbar-Machen fremder Daten kann nach § 303a StGB Datenveränderung sein; besonders schwere Fälle können nach § 303b I Nr. 1 StGB Computersabotage sein und mit Freiheitsstrafe bis zu fünf Jahren oder Geldstrafe bestraft werden. DDoS-Attacken gelten seit 2007 ebenfalls als Computersabotage. Das Ausspähen von Daten nach § 202a StGB kann mit Freiheitsstrafe bis zu drei Jahren oder Geldstrafe bestraft werden. Auch das Abfangen fremder Daten und bestimmte Handlungen mit „Hackertools“ sind seit 2007 strafbar, wenn damit eine Straftat vorbereitet wird (§ 202c StGB). Computerbetrug nach § 263a StGB betrifft manipulierte Datenverarbeitung zur Erlangung von Vermögensvorteilen und kann mit Geldstrafe oder Freiheitsstrafe bis zu fünf Jahren bestraft werden.