Web Application Security ist eine noch sehr junge IT-Disziplin. Eine systematische Darstellung existiert bisher ebenso wenig wie eine methodische Aufbereitung für den praktischen Umgang. Thomas Schreiber und Despina Leonhard von der Securenet GmbH nehmen sich dieser Thematik an.
Web Application Security ist innerhalb einer enthusiastischen Community entstanden, die sich in Mailing-Listen und verschiedenen Open-Source-Projekten zusammengefunden hat. Die Szene ist sehr bewegt, und das Wissen ist auf eine Vielzahl von Veröffentlichungen, zumeist im Internet und in Open-Source-Guides verteilt. Die Alltagsgefahr für Anwender, Dienstleister und Unternehmen, die Web Application Security nicht berücksichtigen, ist wiederum sehr groß.
Bei Web Application Security handelt es sich um die Sicherheit der Webanwendungen selbst. Es geht nicht um die Sicherheit der Plattform oder des Webservers, unter dem die Anwendung läuft, auch wenn deren zuverlässige Funktionsweise eine wichtige Voraussetzung für die Sicherheit der Webanwendung selbst darstellt.
Second Line of Defense unbedingt notwendig
Bei Web Application Security gilt generell der Sicherheitsgrundsatz der "Second Line of Defense". Danach sind Gefährdungen nicht nur durch eine, sondern mehrfache Schutzmaßnahmen abzusichern, um für den Fall, dass die eine Maßnahme umgangen wird oder ausfällt, die Applikation durch eine zweite Sicherungslinie weiterhin geschützt ist.
Grundsätzlich geht es darum, die Ports 80 (http) und 443 (https) zu schützen. Geht das überhaupt? Die Frage, welche Bereiche der IT-Security der Sicherheit von Webanwendungen zuzuordnen sind, lässt sich so nicht mit einer sauberen Abgrenzung beantworten. Die Übergänge sind fließend und die Abhängigkeiten zum Umfeld groß.
Das Sechs-Ebenen-Modell
Die verschiedenen Aspekte der Sicherheit von Webanwendungen lassen sich in einem Sechs-Ebenen-Modell abbilden (siehe Abbildung). Denn bisher wird Web Application Security häufig ausschließlich unter dem Gesichtspunkt der fehlerhaften Programmierung und Konfiguration gesehen.
Die Implementierungsebene ist zwar ein wichtiger Aspekt, aber nur einer von mehreren. Eine Webanwendung kann erst dann als hinreichend sicher eingestuft werden, wenn alle Ebenen betrachtet werden, und auch das - möglicherweise ungünstige - Zusammenwirken der einzelnen Ebenen untersucht worden ist.
Die Web Application Security befindet sich in teilweise enger Abhängigkeit und Wechselwirkung zu anderen Bereichen der IT-Sicherheit. Eine klare Abgrenzung ist jedoch sowohl für die Klärung der Zuständigkeiten wichtig, als auch, um die richtigen Maßnahmen an den richtigen Stellen ergreifen zu können.
Beispielsweise bei der Desktop-Security: Hier geht es um den Schutz des PCs und des Benutzers; im Hinblick auf die Webanwendung, also um die Client-Rolle in der Kommunikation.
Auch der Client muss geschützt werden
Bei der Web Application Security steht demgegenüber der Schutz der Server-Seite im Vordergrund. Doch die Web Application Security muss sich auch mit dem Schutz des Benutzers befassen: Indirekt dadurch, dass sie Sorge dafür trägt, dass beispielsweise das Benutzerkonto von außen nicht einsehbar ist. Beispielsweise geht es darum, dass die Webanwendung einem Betrüger wie einem Phishing-Angreifer den Zugriff auf den Client durch eine XSS-Schwachstelle ("Cross-Site Scripting") nicht noch erleichtert.
Virenschutz ist Teil der Desktop-Security. Eine unsichere Webanwendung kann dazu missbraucht werden, Viren auf einem Weg einzuschleusen, den der Benutzer für sicher hält. Etwa dann, wenn die Webanwendung über eine Schwachstelle (Ebene 3) verfügt, über die Dateien auf dem Server abgelegt werden können.
Auf dem Layer 5 (semantische Ebene) gibt jede XSS-Schwachstelle einem Angreifer die Möglichkeit, über einen präparierten Link einen Virus vermeintlich über diese Webanwendung einzuschleusen, sodass der Benutzer keinen Verdacht schöpft. Auch hier gilt also, dass die Webanwendung keinesfalls die Sicherheit des Benutzers gefährden darf und nicht auch noch dazu beiträgt, dass dieser unter Zuhilfenahme der Webanwendung von einem Dritten getäuscht oder geschädigt werden kann.
Produkte wie Content-Filter und Popup-Blocker sind Gegenstand der Desktop-Security. Sie können den Benutzer teilweise auch vor Gefahren schützen, die durch Fehler in der von ihm benutzten Webanwendung entstehen. Die vom BSI propagierte Schutzmaßnahme, aktive Inhalte inklusive Java Script abzuschalten, gehört ebenfalls zu Desktop-Security. Richtig konfiguriert, ist sie also in der Lage, einige Angriffstechniken aus Webanwendungen heraus zu verhindern.
Netzwerk- und Host-Security für sichere Webanwendung
Netzwerk- und Host-Security schließen sich nach unten an die Ebene 1 an. Beide Bereiche sind die wichtigste Voraussetzung für eine sichere Webanwendung. Trotzdem ist die Netzwerk- und Host-Security klar von der Web Application Security zu trennen: Die Skills, die benötigt werden, um Netzwerk und Hosts abzusichern, sind völlig anderer Natur als diejenigen für die Web Application Security. Dies gilt auch für die organisatorische Einbindung: Die Zuständigkeit für die Netzwerksicherheit ist im Unternehmen an zentraler Stelle verankert. Die Zuständigkeit für die Sicherheit der Anwendung muss wegen der untrennbaren Verzahnung der Software mit den abgebildeten Geschäftsprozessen hingegen beim Fachbereich, von dem sie betrieben werden, angesiedelt werden.
Zu den Sicherheitsanforderungen auf der Ebene 0 gehört seitens der Webanwendung, dass sie eine Second-Line-of-Defense etablieren muss. Besitzt die Webanwendung auf der Ebene 3 einen Fehler, der es einem Angreifer erlaubt, in den Host einzudringen, so darf es diesem trotzdem nicht gelingen, dort Schaden anzurichten, der über den Bereich der betroffenen Webanwendung hinausgeht. Durch entsprechende Konfiguration des Hosts sind Schutzzonen zu schaffen, die dies verhindern.
Vor ihrer Inbetriebnahme ist die Webanwendung nicht nur auf Laststabilität und funktionale Fehlerfreiheit zu prüfen, sich muss sich auch einem Sicherheitstest unterziehen. In den verschiedenen Bereichen sind jeweils unterschiedliche Kenntnisse erforderlich. Der Umfang der hierfür am Markt angebotenen Werkzeuge variiert stark.
Dieses Klassifizierungsschema hat sich als sehr hilfreich für das Verständnis von Schwachstellen in Webanwendungen erwiesen - bei der Darstellung gegenüber Fachfremden ebenso wie bei der Schulung von Softwareentwicklern und Sicherheitsverantwortlichen. Darin sind Schwachstellen und zugehörige Schutzmaßnahmen den Ebenen zugeordnet.
Mangelnde Beachtung von Gesetzen
So werden in vielen Firmen hier zu Lande viele Vorschriften nicht eingehalten: etwa die Bestimmungen zum Datenschutz oder das KonTraG (Gesetz zur Kontrolle und Transparenz im Unternehmensbereich). Vielfach werden Inhalte nicht ICRA-gemäß (Internet Content Rating Association) gekennzeichnet oder vertrauliche Informationen fahrlässig preisgegeben. So genannte Social-Engineering-Angriffe werden durch allgemein zugänglich gemachte Daten und Phishing-Attacken durch den Gebrauch von Popups erst ermöglicht.
Vielfach existiert keinerlei Absicherung gegen gefälschte Websites. Unsichere E-Mails durchlöchern den eigentlich abgesicherten Workflow, Passwörter verlieren ihre Einzigartigkeit durch so genannte "Passwort vergessen"-Funktionen, oft gibt es auch keine Regeln für die Passworterzeugung.
Neben Programmierfehlern in Skripten oder bei Datenbankzugriffen wächst auch die Gefahr von Attacken, die als Session Riding bezeichnetet werden. Hierbei kann ein Angreifer über manipulierte Links eigene Daten der Webapplikation übergeben. Der User löscht daraufhin unbemerkt Daten oder er versendet ohne sein Wissen Spam-Mails. Die Konfiguration von webgesteuerten Routern und Firewalls lässt sich so leicht ändern.
Viele Unternehmen setzen auch Einmal-Passwörter ein, die nicht wirklich "zufällig" erzeugt werden, sie übertragen sensitive Daten unverschlüsselt, oder setzen Authentifizierungsverfahren ein, die dem Schutzbedarf der Daten nicht angemessen sind. Oft wird der Webserver selbst auch falsch konfiguriert und bekannte Schwachstellen nicht beseitigt.
Aufgrund der starken Abhängigkeiten der hier erwähnten Security-Ebenen ist ein allgemeiner Leitfaden zu Beseitigung von Schwachstellen so einfach nicht zu erstellen. Bestehende Anwendungen und Neuentwicklungen müssen getrennt voneinander auf ihre Sicherheit hin geprüft werden.
Webshield ersetzt keine Netzwerk-Firewall
Man darf keinesfalls von der weit verbreiteten, aber falschen, Annahme ausgehen, dass eine unsichere Webanwendung dann zu keinem Schaden führt, wenn sie selbst keine sensiblen Daten bereitstellt oder sicherheitsrelevante Funktionen ausführt. Eine einzige unsichere Webanwendung kann die Sicherheit des gesamten Systems kompromittieren, wie die Attacken via SQL-Injection oder Session Fixation gezeigt haben. Es ist also die gesamte Site mit all ihren Hosts, Domains, Anwendungen und Auftritten auf ihre Sicherheit zu untersuchen, und alle Schwachstellen sind auf jeden Fall zu beheben.
Eine sinnvolle Maßnahme zur zusätzlichen Absicherung von Webanwendungen stellen so genannte Webshields dar, die als Application Firewalls agieren. Die Einführung eines Webshields sollte jedoch keinesfalls ohne eine Untersuchung der Sicherheit bestehender Anwendungen geschehen. Zu schnell führt dies in der Regel zum Glauben, man wäre nun abgesichert. Denn ein Webshield liefert keinesfalls das gleiche Maß an Sicherheit wie eine Firewall auf der Netzwerkebene.
Kein Königsweg in der Web Application Security
Die komplexe Natur der Web Application Security bringt es mit sich, dass es keinen Königsweg zu einer sicheren Webanwendung gibt. Einzelne Maßnahmen bringen manchmal Randbedingungen mit sich, die denen anderer Maßnahmen direkt widersprechen.
Der Entscheider und der Dienstleister sind daher gleichermaßen wie der Entwickler aufgefordert, die jeweiligen Maßnahmen vor dem Hintergrund der Erfordernisse der jeweiligen Anwendungen zu bewerten und diese geeignet anzupassen. Das Sechs-Ebenen-Modell der Web Application Security sollte Ihnen helfen, neue und bestehende Gefahren zu erkennen, die Verantwortlichkeiten besser zu definieren und die richtigen Entscheidungen für Ihre Bedürfnisse zu treffen.