What is web Application Security

Es richtet sich in erster Linie an die technischen Entscheidungsträger - insbesondere Betriebsleiter, Sicherheitsbeauftragte, Applikationsverantwortliche (Fachabteilung, Anwendungstechniker), die den Nutzen einer WAF im Betrieb bewerten. Für die Entscheidung über den Gebrauch von WAFs kann neben der Bedeutung der Webanwendung für das eigene Geschäft, z.B. Vertrieb oder Bild, der Ausdruck "Zugriff" auf eine im Text beschriebene Webanwendung ein gutes Entscheidungskriterium sein.

Im Klartext: Der Zugang zu einer speziellen Web-Anwendung durch ein Unter- nehmen gibt an, in welchem Umfang das Unter- nehmen in Echtzeit die notwendigen Veränderungen am Quellcode der Anwendung selbst vornehmen oder von Dritten vornehmen kann. Eine Web-Anwendung, auf die das Unternehemen keinen Zugang hat, kann nur durch eine WAF (hoher Vorteil der WAF) sinnvoll abgesichert werden, während selbst bei einer Anwendung im Vollzugriff eine WAF als zentraler Servicepunkt für verschiedene Services wie das sichere Session-Management, das für alle Anwendungen gleichermaßen lösbar ist, und als geeignetes Mittel für vorausschauende Schutzmassnahmen wie die URL-Verschlüsselung noch erhebliche zusätzliche Vorteile hat.

Ein weiterer Schwerpunkt sind Best Practices für die Organisationsprozesse bei der Einrichtung und dem Betreiben einer WAF und - insbesondere für große Firmen - eine Ausweitung der Prozessorganisation um die Funktion der anwendungsverantwortlichen WAF. Sie sind Angestellte von Firmen, die über den Gebrauch und die Bedienung von WAF' s beratend tätig sind, WAF' s verwenden und/oder WAF' s produzieren.

Absichtlich wurde auf ein Lexikon ganz gezielt verzichtet, so dass der Rahmen übersichtlich und inhaltlich auf das Wesentliche beschränkt ist - den Gebrauch von Web Application Firewalls. Detaillierte Erläuterungen zu Begriffen und weitere Erläuterungen im Rahmen von WAS - Web Application Security - erhalten Sie unter: Zugelassen. Hier haben viele Schwachpunkte ihren Ursprung: HTTP ist z.B. stateless, d.h. Sitzungen oder Anwendungszustände müssen getrennt voneinander festgelegt und gesichert werden.

Das vorliegende Papier behandelt eine Art von Sicherheitssystemen, die Web Application Firewalls (WAF), die sich besonders für die Sicherung bereits lauffähiger Web-Anwendungen eignen. Eine WAF ist in diesem Handbuch eine Web Application Level Protection-Lösung, die nicht von der Applikation selbst abhängt. Es richtet sich in erster Linie an die technischen Entscheidungsträger - insbesondere Betriebsleiter, Sicherheitsbeauftragte, Applikationsverantwortliche (Fachabteilung, Anwendungstechniker), die den Nutzen einer WAF im Betrieb bewerten.

Ein weiterer Schwerpunkt sind Best Practices für die Organisationsprozesse bei der Einrichtung und dem Betreiben einer WAF und - insbesondere für große Firmen - eine Ausweitung der Prozessorganisation um die Funktion der anwendungsverantwortlichen WAF. Im Hinblick auf die Wichtigkeit der Sicherheitsaspekte der im Konzern verwendeten Webanwendungen müssen viele Gesichtspunkte beachtet werden - insbesondere bei grösseren Firmen.

Eine der bedeutendsten ist die Zahl der leistungsfähigen Web-Anwendungen im Unter-nehmen. Große Firmen arbeiten oft - intern oder auch extern - mit weit über 100 Web-Applikationen. Selbst wenn die Prioritätensetzung jeder individuellen Web-Anwendung im Hinblick auf ihre Wichtigkeit für den Erfolg des Unternehmens unverzichtbar und sehr nützlich ist, ist zu beachten, dass alle intern eingesetzten Web-Anwendungen - je nach Systemarchitektur - durch geeignete Angriffstechniken den Zugang zu den internen Systemen des Unternehmens bereitstellen.

Weitere Gesichtspunkte wie z. B. Risiko und Aufwand s. Kapitel 3 und 6 Absatz 4.4 Die Auswahl geeigneter Sicherheitsmassnahmen für eine Webanwendung hängt wesentlich von der entsprechenden Entwicklungsphase der Applikation ab. In der Entwurfsphase können noch passende Tools für Implementierungs-, Test- und Qualitätssicherungs-Tools gewählt werden, bei Bedarf können zudem Developer im Bereich Web Application Security trainiert und die entsprechenden Timelines bis zum Going Live aufgesetzt werden.

Erst wenn diese Voraussetzungen gegeben sind, kann die Anwendung innerhalb der vorhandenen Applikationsinfrastruktur überhaupt gesichert werden - ohne Rücksicht auf den Zeitaufwand. Prinzipiell sollte jede Webanwendung so gut wie möglich geschützt sein. Je später ein Schwachpunkt im Lebenslauf einer Webanwendung entdeckt wird, umso größer ist das damit einhergehende Einbruchsrisiko - und oft auch der Korrekturaufwand.

Werkzeuge wie Stinger beziehen sich in der Regel nur auf ein Rahmenwerk - im Beispiel J2EE; sie sind Teil der Anwendung (auch wenn sie zu fertig gestellten J2EE-konformen Anwendungen hinzugefügt werden können) und unterliegen daher in der Regel dem üblichen Anwendungsfreigabezyklus in organisatorischer Hinsicht. Grundsätzlich sind sie eine effektive Unterstützung für den Anwender, um seine - besondere - Anwendung abzusichern.

Sie sind jedoch im Gegensatz zu WAFs immer Teil der Anwendung. Darüber hinaus werden Durchdringungstests durchgeführt - vorzugsweise von Fachleuten, die auch im laufenden Betrieb Schwachpunkte im äußeren Erscheinungsbild der Webanwendung erkennen. Die Hauptaufgabe einer WAF besteht dabei darin, mit geringstem Einsatz Schwachpunkte im äußeren Erscheinungsbild von Webanwendungen so zu sichern, dass sie von einem Angreifer nicht ausgebeutet werden können.

Durch die bereits hohe Kompliziertheit einer klassischen Applikationsinfrastruktur - Webserver, Applikationsserver, verwendete Frames - sowie die typische Komponente einer Webanwendung - Session-Handling mit Cookie, Input-Validierung usw. - ist die Nutzung der Webanwendung sehr komplex. Das Hauptziel einer WAF ist daher der spätere Schutz bereits vorhandener, oft leistungsfähiger Webanwendungen, bei denen erforderliche Veränderungen innerhalb der Anwendung nicht mehr oder nur noch mit unverhältnismäßigem Mehraufwand vorgenommen werden können.

Das betrifft besonders Sicherheitslücken, die z.B. durch einen Penetration Test oder eine Quellcodeanalyse identifiziert wurden und die innerhalb der Software - besonders bei kurzfristigen Anfragen - nicht behoben werden können. Die WAF-Regeln beschreiben im Whitelist exakt das von der jeweiligen Software geforderte Benehmen; die Einrichtung von geeigneten Whitelisten wird oft durch Lern-Modi untermauert.

Zusätzlich verfügen einige WAF über Funktionen, die über den rein schutztechnischen Charakter hinaus gehen und daher auch im Design-Prozess zur Vermeidung von unnötigem Arbeitsaufwand Berücksichtigung finden können. Der WAF wird damit zur Anlaufstelle für die Ausführung von Aufgabenstellungen, die natürlich auf der Anwendungsseite stehen, aber für alle Applikationen gleich gelöst werden können.

In der nachfolgenden Übersicht sind die bekanntesten Sicherheitslücken bzw. Angriffsmöglichkeiten von Webanwendungen aufgelistet, die Ihnen hier zur Verfügung stehen. Im Regelfall werden die von der WAF verwendeten Funktionalitäten erwähnt, obwohl nicht alle auf dem freien Handel erhältlichen sind. Die folgende Liste enthält die mögliche Sicherheitsmechanismen (Spalte Aktion) für die typischen Gefahren, Verwundbarkeiten und Attacken (Spalte Problem), und die WAF-Säule beurteilt, wie gut eine WAF die Applikation schützt.

Selbst wenn die Sitzungen von der Anwendung zur Verfügung gestellt werden, kann die WAF sie bei entsprechendem Aufbau automatisch wiedererkennen und beenden. Der hier beschriebene Nutzen von WAFs wird detailliert erläutert, vor allem anhand der ausführlichen Übersicht im folgenden Teil. Die Hauptvorteile von WAFs liegen in der späteren Sicherung des Außenverhaltens bereits fertiggestellter, produktiver Webanwendungen mit einem vertretbaren Arbeitsaufwand und ohne Veränderung der Anwendung selbst.

Zum einen mit einer gewissen Grundabsicherung gegen bekannt gewordene Angriffe oder -schwächen auf der Grundlage von Blacklists: Beispielsweise bietet der Datensicherheitsstandard der Kreditkartenbranche (PCI DSS v.1. 1) in seiner aktuell geltenden Fassung den Gebrauch einer WAF - als Alternative zu regulären Code Reviews durch Fachleute - als ausreichenden Maßnahmenschutz für die eingesetzten Webanwendungen.

Die Vorteile von WAFs werden besonders bei konkreten Schwachpunkten sichtbar, die z.B. durch Penetration Tests oder Source Code Reviews entdeckt werden. Auch wenn die Sicherheitslücke in der Anwendung schnell und mit angemessenem Arbeitsaufwand behoben werden konnte, kann die veränderte Variante in der Regel erst im nächstfolgenden Wartungszeitraum, oft 2-4 Wochen später, installiert werden (Patchdilemma).

WAFs, die z.B. mit Quellcode-Analysetools so zusammen arbeiten können, dass entdeckte Schwachpunkte zu Regelungsvorschlägen für die WAF werden, sind hier besonders zügig. Eine WAF ist besonders wichtig bei Produktiv-Webanwendungen, die selbst aus vielen Bausteinen zusammengesetzt sind, die vom Anwender nicht kurzfristig gewechselt werden können - z.B. bei schlecht belegten Applikationen oder Fremdprodukten ohne ausreichende Wartbarkeit.

Die WAF kann als zentraler Servicepunkt für jede Applikation die gleichen Aufgabenstellungen annehmen. Zahlreiche Waffensysteme verfügen auch über einen proaktiven Schutzmechanismus wie URL-Verschlüsselung oder Site-Use-Enforcement, um die Angriffsoberfläche mit minimalem Arbeitsaufwand zu reduzieren. Zusätzlich wird durch den WAF die Stabilität der Webapplikationen nach aussen hin gesteigert.

Abhängig von der Art der Implementierung bietet WAFs auch zusätzliche Vorteile. Das ist im Betrieb gelegentlich erwünscht, kann aber auch durch geeignete Web Application Security Add-ons von bereits im Einsatz befindlichen Produkten erreicht werden. WAFs, die als Plug-in im Web-Server realisiert sind, sind hier besonders gut einsetzbar. Der WAF kann auch eine SSL-Terminierung anbieten, wenn die zu sichernde Applikation oder ihr Web- oder Anwendungsserver nicht über diese Möglichkeit verfügt.

Bei der Nutzung einer WAF ist zu berücksichtigen, dass ein Eingreifen in die bestehende IT-, Web- und ggf. Anwendungsinfrastruktur notwendig ist. Anhand dieser drei Kategorien werden exemplarisch Schutzmassnahmen innerhalb der Anwendung oder der Anwendungsarchitektur selbst, unter Verwendung von WAFs und den Spezifikationen einer geeigneten Policy ausführlich vorgestellt und im Hinblick auf den dafür erforderlichen Aufwand evaluiert.

Teilweise wird auf besondere Funktionen von WAFs oder auf Vermutungen über die eingesetzte Applikationsinfrastruktur verwiesen, da diese in der Regel nicht gelten. Die folgende Übersicht verdeutlicht, dass der Gebrauch von WAFs sehr oft mit dem wenigsten Arbeitsaufwand einhergeht, insbesondere bei bereits laufenden Aufträgen. Für bereits produktive Applikationen, die nicht oder nur bedingt adaptierbar sind, ist der Gebrauch von WAFs in einigen Bereichen die einzige Möglichkeit des Schutzes.

Die folgende Übersicht listet Anmerkungen und Tipps (Spalte Top 10) zu den Gefahren für die entsprechenden Applikationsklassen T1, T2, T3, den Gebrauch einer WAF oder durch das Implementieren einer Richtlinie (Spalte Typ) auf und beurteilt (Spalte Aufwand), wie groß der jeweilige Implementierungsaufwand für eine gesicherte Implementation ist.

Die Durchsetzung der Website-Nutzung kann den Zugang zu bestehenden, aber unveröffentlichten (unverknüpften) Dokumenten unterbinden. Die WAF kann die Authentifizierung anwendungsunabhängig durchführen und so eine Verbindung zu einer zentralen Authentifizierungsinfrastruktur herstellen, ohne die Anwendungen zu verändern. WAF-Nutzer können auf die von der Software als Links erhaltenen Webseiten mit Hilfe von Seiten-Tokens oder URL-Verschlüsselung beschränkt werden.

Allerdings darf die Bewerbung keine geschützten Verknüpfungen darstellen (eingeschränkte Zugriffsmuster). Nachfolgend wird das Konzept des Zugangs des Betriebes zur Webanwendung vorgestellt und erörtert. Anhand der Prüfliste in Anlage 8.1 wird der Zugriffsgrad für jede Webanwendung einzeln über ein Punktesystem ermittelt. Die Zugänglichkeit einer Web-Anwendung sollte ein Maßstab dafür sein, in welchem Umfang das Untenehmen die notwendigen Veränderungen an der Web-Anwendung - also letztendlich den Quellcode der jeweiligen Software - unverzüglich umsetzen und erzwingen kann.

In der Entwurfsphase kann eine Web-Anwendung (siehe Abschnitt 1 in 5) als Sonderfall einer Web-Anwendung mit optimaler Zugänglichkeit angesehen werden. Ein anderes Extremformat einer Webanwendung ohne Zugang ist zum Beispiel eine Anwendung, die aus vielen undokumentierten Bausteinen zusammengesetzt ist, deren Hersteller auch nicht mehr erreichbar sind und die Softwareprodukte von Drittanbietern verwenden, die nicht mehr vom Hersteller gewartet werden - in Open-Source-Projekten der Community (siehe T3 in 5).

Entscheidende Faktoren für den Zugriff auf eine Web-Anwendung sind: geringe Fehlersuchzeiten durch den jeweiligen Drittanbieter (Portale, Frames, SAP, etc.). Die weiteren wichtigen Punkte pro Webanwendung sind in der Prüfliste im Appendix ersichtlich. Verwenden Sie die Prüfliste in Anlage 8.1, um die Zugriffsebene für jede Webanwendung zu ermitteln.

Dies kann auch verwendet werden, um einen durchschnittlichen Zugriffswert für alle Webanwendungen eines Betriebes zu bestimmen, allerdings ist zu berücksichtigen, dass auch Anwendungen, die für den Erfolg oder das Erscheinungsbild des Betriebes besonders wichtig sind, eine entsprechende Gewichtung erhalten müssen. Die folgende Beschreibung kann als Orientierungshilfe bei der Entscheidung über den Einsatz einer WAF in einem Betrieb dienen:

Verfügt ein Unternehemen über Vollzugriff auf alle Webanwendungen, minimiert der WAF den betrieblichen Aufwand - vor allem durch die zusätzlichen Vorteile einer WAF als zentraler Servicepunkt, die unter 3 erwähnt werden, und einige verhältnismäßig leicht zu implementierende Absicherungsmechanismen.

Bei sinkendem Zugang zur Web-Anwendung - und je nach Wichtigkeit und Umfang - steigt der Vorteil des Einsatzes einer WAF sehr schnell - von einer zweiten Verteidigungslinie zu einer wirklichen Vollabdichtung der Web-Anwendung nach aussen über eine Whitelistung - da eine WAF im Gegensatz dazu oft den wenigsten zusätzlichen Aufwand für die nötige Sicherheit aufbringt.

Einsparung durch die Nutzung zentraler Dienste, die von einer WAF für mehrere Web-Applikationen bereitgestellt werden und daher nicht mehr in jeder Applikation selbst realisiert oder eingerichtet werden müssen. Beim Sichern von nicht ausreichend zugänglichen Applikationen (siehe Punkt 6.2), deren Sicherung jedoch als erforderlich angesehen wird, können die Ausgaben für die Nutzung einer WAF entweder als strategisches Investment angesehen werden oder, falls realistisch, mit den Ersetzungskosten der jeweiligen Applikation verrechnet werden.

Der Aufwand für den Betrieb einer WAF setzt sich in der Regel aus den nachfolgenden Bestandteilen zusammen: Prinzipiell ist zu beachten, dass WAFs in die vorhandene Webinfrastruktur - und deren geplanten oder absehbaren Änderungen - integriert werden müssen und nicht andersherum die gesamte Struktur durch die Einführung einer WAF verändert werden sollte.

Vielmehr sind die typischen Kennziffern einer Web-Anwendung wie die Zahl der simultanen Nutzer der Anwendung und die Zahl der HTTP-Requests pro Einheit im Durchschnitt und in daraus abgeleiteten Spitzenlasten. Dabei ist zu berücksichtigen, dass viele Anwendungen Spitzenlastphasen aufweisen, die nur in seltenen Fällen vorkommen, z.B. im Weihnachtsgeschäft bei einem Webshop.

Vorhandene Sicherheitspolitiken sollten so weit wie möglich nicht durch die Einführung einer WAF verändert werden müssen. Dies wird gerade in Hochsicherheits-Infrastrukturen oft durch die vorhandenen Sicherheits-Richtlinien ausgeklammert und kann auch durch den Gebrauch eines passenden WAF - als Plug-In im Web-Server hinter der SSL-Terminierung im Web-Server - aufrechterhalten werden.

Die nachhaltige Nutzung von WAFs ist auch nach der einmaligen Beauftragung maßgeblich vom reibungslosen Zusammenwirken der WAF mit allen anderen Bestandteilen der Applikationsinfrastruktur abhängig. Dies umfasst auf der einen Seite offenkundige Fragen wie das Verstehen und entsprechende Reaktionsoptionen auf WAF-Fehler- und Fehlermeldungen, aber auch Fragen wie die Adaption der WAF-Regeln für gewünschte Veränderungen der zu sichernden Anwendungen.

Daher wird neben der Funktion eines für die Plattform verantwortlichen WAF, der für die Infrastrukturaspekte der WAF zuständig ist, eine neue Funktion einer für die Plattform verantwortlichen Applikation vorgeschlagen, die im übertragenen Sinne die Verbindung zwischen der WAF und der Geschäftsanwendung ist. Um die WAF zu projektieren und anwendungsspezifisch zu kontrollieren, muss er über ausgezeichnete Fachkenntnisse verfügen.

Um Berichte der WAF klassifizieren und auswerten zu können, muss er die Applikation gut beherrschen. Das vorgeschlagene Rollenmodell ist in Anlage 8.3 ausführlich beschrieben Ein iterativer Ansatz hat sich bei der Umsetzung und dem Einsatz von WAFs als best practice erwiesen. Dadurch wird sichergestellt, dass alle Anwendungen, die noch nicht in Produktion sind, so schnell wie möglich die Zentralfunktionen der WAF ausnutzen.

Ungeachtet der Eigenschaften der entsprechenden Webanwendung wird zunächst der Basisschutz, in der Regel als Blacklisting implementiert, eingeschaltet. - ist die Zugriffsmessung auf die Webanwendung gemäß der Prüfliste in Anlage 8.1. Gewöhnlich werden die Webanwendungen durch den Lernmodus der WAF oder den Quellcode-Review/Penetrationstest gestützt und nach der Prioritätsliste mit Whitelist-Regeln nach aussen hin vollständig versiegelt.

In Kooperation mit dem Application Manager stellt der Application Manager WAF die jederzeitige problemlose Zugänglichkeit der Applikation nach aussen sicher - auch bei der Umsetzung der Regelwerke. Die folgende Liste kann verwendet werden, um den Zugang eines Unternehmens zur Webanwendung zu bewerten. Die Anzahl der gesammelten Messpunkte erhöht den Zugang zu einer Webanwendung.

Den Entwicklern, die die Anwendung entwickelt und umgesetzt haben, steht weiterhin die Möglichkeit zur Anpassung zur VerfÃ?gung. Es bestehen für die Anwendung und alle in der Anwendung verwendeten Bestandteile (Webserver, Applikationsserver, Datenbank, etc.), die eine Fehlerkorrektur enthalten oder für Open Source Bestandteile gibt es eine rege Gemeinschaft, die diese Bestandteile weiter entwickelt. Für die Qualitätskontrolle der Anwendung bestehen automatische Prüfungen, die ein hohes Maß an Testabdeckung darstellen und in neuen Versionen eingesetzt werden.

Die Sicherheit in dieser Umgebung führt jedoch dazu, dass die unerwünschte Funktion nicht zur Verfügung steht -> hilft in der Regel nicht viel. Im Zuge der Anwendungsentwicklung und -fortentwicklung wurde eine automatische Quellcodeanalyse (Whiteboard-Test) mit dem Schwerpunkt Anwendungssicherheit durchführt. Weniger als 1000 Std. reine Implementierungszeit (ohne Projektmanagement) flossen in die Anwendungsentwicklung, inklusive aller weiteren Entwicklungen.

In der Anwendungsarchitektur ist ein zentraler Regler enthalten, über den alle Eingänge zur Anwendung und aus dem Anwendungslauf (MVC) erfolgen. Das Programm verwendet ein Sicherheits-Framework, das unter anderem Validierer/Filter für die Ein- und Ausgaben bereitstellt. Es wurde ein Sicherheitsaudit/Durchdringungstest an der Anwendung vorgenommen und alle während des Audits identifizierten Sicherheitslücken wurden beseitigt.

Programmierer sind in Sicherheitsfragen ausgebildet und verfügen über Erfahrung. 5Die wichtigsten sind immer ausgebildete Programmierer! Die hier geschilderte Vorbildfunktion sollte vor allem dann realisiert werden, wenn die WAF - neben ihrer Aufgabe als Second Line of Defense und einer Basissicherheit - die Aufgabe im Sinn des im vorliegenden Dokuments dargestellten Whitelists zum Schutze der Web-Applikationen übernehmen und damit dem externen Nutzungsverhalten der Web-Applikation weitestgehend folgen.

Ein Vorbild, in dem die Verantwortung aller Parteien im ganzen Software-Entwicklungszyklus festgelegt ist, ist jedoch für den nachhaltigen Erfolg einer WAF mitentscheidend. Sie können sich in ihrer Ausstattung und ihrem Nutzungsverhalten von Release zu Release erheblich voneinander abheben. In sehr vereinfachter Form wird nicht mehr eine einzige Instanz einer Applikation projektiert, sondern jedes Eingangsfeld einer Applikation.

Bei grösseren IT-Organisationen wird der Netzwerkbetrieb, zu dem die Brandmauer zählt, und die Applikationen von unterschiedlichen Stellen, teilweise auch von unterschiedlichen Unternehmen ausgeführt. Hier wird die neue Funktion des Application Managers WAF vorgeschlagen, die sich zwischen der WAF-Plattform und der einzelnen Applikation befindet. Die WAF ist die Schnittstelle zwischen der WAF und der Geschäftsanwendung.

Um die WAF zu projektieren und anwendungsspezifisch zu kontrollieren, muss er über ausgezeichnete Fachkenntnisse verfügen. Um Berichte der WAF klassifizieren und auswerten zu können, muss er die Applikation gut beherrschen. Dabei werden zum einen die besonderen Voraussetzungen für den gesicherten und leistungsfähigen Einsatz einer WAF und zum anderen die klassische Rolle des Infrastruktur- bzw. Plattformmanagers und Applikationsmanagers aus hochstrukturierten Unternehmen beibehalten.

Gute Kenntnis des externen Verhalten der Applikation, besonders Input, Output, Upload, Download, Zeichensatz, etc.