Web-Applikationen Firewall - Grundlagen und Marktübersicht

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name des Autors / der Authoren: Philipp Rost
Titel der Arbeit: "Web-Applikationen Firewall - Grundlagen und Marktübersicht"
Hochschule und Studienort: FOM Düsseldorf


Inhaltsverzeichnis

1 Abkürzungsverzeichnis

AbkürzungBedeutung
WWWWorld Wide Web
URLUniform Resource Locator
WAFWeb Applikation Firewall
HTTPHyper Text Transport Protocol
OWASPOpen Web Application Security Project
PCI DSSPayment Card Industry Data Security Standard
OSIOpen Systems Interconnection

2 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1OSI-Referenzmodell
2Statistik zu OWASP Top 10
3Statistik zu PCI DSS Standard
4Netzwerkstruktur mit WAF als Netzwerkmodul
5Netzwerkstruktur mit WAF als Proxy
6Netzwerkstruktur mit WAF als Embedded
7HTTP Traffic auf der Netzwerkebene

3 Einleitung

Webanwendungen aller Art, […], werden in den letzten Jahren nachweislich immer stärker zur Zielscheibe von Hackerangriffen.[1] Dies ist auf den Web 2.0 Hype zurück zuführen, da Web Applikationen immer komplexer wurden und Web Applikationen für den Benutzer, und auch für den Angreifer, durch das Internet immer zur Verfügung stehen.[2] Ziel dieser Hausarbeit ist es dem Leser einen Überblick über die Grundlagen einer Web Applikationen Firewall, sowie einen Marktübersicht über Web Applikation Firewall Hersteller zu geben. Grundlage hierfür ist eine Übersicht von Angriffsszenarien gegen Web Applikationen sowie Statistiken, die die Anfälligkeit von Web Applikationen für Angriffe zeigen. Des Weiteren werden grundlegende Techniken erläutert, wie Web Applikationen Firewalls Angriffe erkennen und Schwachstellen schließen. Darüberhinaus folgt eine Marktübersicht zu den spezifischen Arten von Web Applikationen Firewalls.

4 Grundlagen

4.1 Client-Server-Modell

Die Clients fordern über WWW-Verbindungen Server-Dienste ein, z.B. Zugriff auf Web Applikationen. Diese Dienste sind auf einem Webserver hinterlegt, der die gewünschten Daten dem Client zur Verfügung stellt.
Proxy-Server:
Ein Proxy erfüllt die Beschaffungswünsche lokaler Clients, indem er stellvertretend für diese nach außen hin aktiv wird. Meistens wirkt er zusätzlich als Speicher und kann Zugriffskontrollstrategien umsetzen. [3]
Load Balancer:
Der Load Balancer ist ein Lastverteiler, der die Antwortzeiten und Auslastung einzelner Server beurteilen kann und eine Anfrage von außen mit der bestmöglichen Server-Performance bedienen kann. [4]

4.2 OSI-Referenzmodell

Abbildung 1: OSI-Referenzmodell
Abbildung 1: OSI-Referenzmodell[5]

Das OSI-7-Schichtenmodell ist ein Referenzmodell für herstellerunabhängige Kommunikationssysteme. Jede Schicht bietet der darüber liegenden Schicht definierte Dienste an und nutzt seinerseits die Dienste der darunter liegenden Schicht. Die Schichten eins bis vier sind die transportorientierten Schichten, von der physikalische Datenübertragung bis zu den physikalischen Endpunkten der Systeme. Die Schichten fünf bis sieben sind anwendungsorientierte Schichten, die Handhabung von den Schnittstellen.[6]




4.3 PCI DSS Standard

Der PCI-Standard wurde durch den PCI Security Standards Council entwickelt. Bekannte Kreditkartenorganisationen und -herausgeber wie American Express, MasterCard, Visa oder JCB International sind maßgeblich daran beteiligt, die Sicherheit von Kartendaten auf globaler Ebene zu verbessern und so Händler und deren Kunden vor Zahlungsausfällen und Betrügereien zu schützen. Der Standard versucht, möglichst alle Aspekte im Bereich Kartenzahlung mit einzubeziehen. Die Netzwerkarchitektur der Unternehmen wird daher genauso betrachtet wie der Umgang mit kritischem Datenmaterial seitens der Mitarbeiter.

Die PCI-Anforderungen im Überblick

  1. Einrichtung und Instandhaltung der Firewall-Konfiguration zum Schutz der Daten
  2. Keine Verwendung der vom Händler ausgelieferten und voreingestellten System-Passwörter bzw. anderer Sicherheitsparameter
  3. Schutz der gespeicherten Daten
  4. Verschlüsselte Übertragung der Karteninhaberdaten und sensibler Informationen über öffentliche Netze
  5. Gebrauch und regelmäßige Aktualisierung der Anti-Viren-Programme
  6. Entwicklung und Aufrechterhaltung von sicheren Systemen und Anwendungen
  7. Beschränkung des Zugriffs auf die Daten nach dem need-to-know-Prinzip
  8. Zuweisung von eindeutigen Kennungen an alle Personen mit Computer-Zugriff
  9. Einschränkung des physischen Zugangs zu Karteninhaberdaten
  10. Verfolgung und Überwachung aller Zugriffe auf Netzwerk-Ressourcen sowie Karteninhaberdaten

[7]

5 Angriffsszenarien an Web-Applikationen

Dieser Abschnitt behandelt grundlegende Angriffsmethoden, die laut OWASP (The Open Web Application Security Project) die gefährlichsten Attacken auf Web Applikationen sind. Des Weiteren werden Statistiken zu diesen Angriffen auf Web Applikationen vorgestellt.[8]

5.1 Angriffsszenarien

5.1.1 Cross-Site Scripting

Mit dieser Methode kann ausführbarer Code über eine Web Applikation verteilt werden und mit dem Browser ausgeführt werden. Dadurch ist es möglich durch den ausführbaren Code auf sensible Daten zu zugreifen. Ebenfalls ist es möglich den Browser so zu manipulieren, dass er auf eine andere Seite umleitet. Bei Cross-Site Scripting unterscheidet man zwischen zwei Methoden. Beständige und nicht beständige Methoden. Bei der beständigen Methode werden Links, während man die Webseite besucht, manipuliert, so dass eine Seite aufgerufen wird und damit der schadhafte Code. Wohingegen nicht beständiger Code auf eine Webseite eingebunden wird und von dort an den Benutzer übergeben wird.[9]

5.1.2 Injection Flaws

5.1.2.1 SQL-Injection

Viele Web Applikationen nutzen Benutzereingaben. Diese basieren meistens auf Datenbanken und führen im Folgenden eine Datenbankabfrage durch. Somit kann man die Eingabe so manipulieren, dass z.B. die Abfrage auf die Datenbank ein ganz anderes Ergebnis liefert. Dazu ein Beispiel:
"SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthCheck = etQueryResult(SQLQuery)
In diesem Fall würde nach Benutzername und Passwort gefragt werden. Die Abfrage würde dann an die Datenbank gehen und den Benutzer mit dem Passwort finden und somit den Wert „true“ zurückgeben. Dadurch erhält der Benutzer beispielsweise die Berechtigung zu einem internen Bereich einer Web Anwendung. Sollte das Kennwort oder Benutzer nicht stimmen sendet er ein „false“ zurück, somit ist dem Benutzer der Zutritt nicht erlaubt. Gibt man nun anstelle des Benutzer bzw. des Passwortes folgendes ein, so erhält der Ausdruck eine völlig andere Bedeutung.
Login: ' OR ='
 Passwort: ' OR ='
 Somit würde in der Abfrage immer ein “true” zurückliefern und der Angreifer wäre mit dem ersten Benutzer der in der Datenbank hinterlegt ist, angemeldet.[10]

5.1.2.2 SSL-Injection

SSL-Injection ist eine serverseitige Methode einen Angriff auszuführen. Es wird dem Angreifer erlaubt einer Web Anwendungen einen ausführbaren Code zu senden. Dieser wird dann zu einem späteren Zeitpunkt auf dem Server ausgeführt. Da ein Webserver zuerst die gesamte zu sendende Seite analysiert, werden die SSL-Befehle direkt mit ausgeführt. [11]

5.1.3 Malicious File Execution

Diese Schwachstelle wird sehr häufig in Web Applikationen gefunden, die eine Upload-Funktion bzw. einem Nutzer die Möglichkeit anbieten eine URL oder ähnliches zu hinterlegen. Wenn diese Daten nicht ausreichend überprüft werden, ist es möglich für einen Angreifer Zugriff zu den Systemen gelangen. Somit erhält der Angreifer die Möglichkeit Remote Code ausführen.[12]

5.1.4 Insecure Direct Object Reference

Wie der Name schon sagt, werden bei dieser Schwachstelle von Web Applikationen Objektreferenzen manipuliert, um somit auf Daten zugreifen zu können. Objektreferenzen können z.B. Daten, URLs oder Verzeichnisse sein.[13]

5.1.5 Cross-Site Request Forgery (CSRF)

In diesem Fall wird einem Nutzer die Session-ID von einem Angreifer übernommen. Sollte ein Nutzer sich an einer Web Applikation angemeldet haben und greift so lange er noch angemeldet ist auf eine Webseite zu, die manipuliert wurde, so ist es für den Angreifer möglich diese Session für die Web Applikation zu übernehmen. [14]

5.1.6 Information Leakage

Diese Methode analysiert den Quellcode der Web Applikation. Es wird geprüft, ob innerhalb des Quellcodes Kommentare oder Verweise der Entwickler hinterlegt wurden, die Informationen enthalten mit denen Angreifer potenzielle Schwachstellen entdecken können. Diese Informationen können mit Fehlermeldungen provoziert werden. Diese Methode ist im Grunde kein Risiko sondern nur eine Informationsbeschaffung für folgende Angriffe. [15]

5.1.7 Broken Authentication

Ungenügende Authentifizierung besteht, sobald eine Person auf Inhalte oder Funktionen von Webseiten zugreifen kann ohne, dass er sich authentifizieren musste. Ein Beispiel können Administrationsordner der Webseiten sein. Obwohl kein Link zu den entsprechenden Seiten führt, können diese Inhalte durch ausprobieren heraus-gefunden werden. Daher müssen solche Inhalte umfangreich geschützt werden. [16]

5.1.8 Session Management

5.1.8.1 Credential / Session Prediction

Die Methode Credential / Session Prediction wird genutzt, um eine Session eines anderen Benutzers zu übernehmen, bzw. sich als ein anderer Benutzer ausgeben. Durch Erraten oder anderen Angaben wird der Wert einer Session bestimmt. Dies ist auch eher bekannt als Session-Hijacking. Damit ist es möglich, dass sich der Angreifer als ein anderer Benutzer ausgeben kann und somit dessen Berechtigungen besitzt. Üblicherweise muss sich ein Benutzer mit Benutzername und Kennwort identifizieren, um seine Berechtigungen zu erlangen. Damit die Webseite jedoch nicht jedes Mal die vertraulichen Daten bei einer Transaktion mitschicken muss, verwenden viele Webseiten Session-ID’s. Diese Session-ID wird häufig mit einem Algorithmus erzeugt oder mit komplexeren Methoden.[17]

5.1.8.2 Insufficient Session Expiration

Bei Insufficient Session Expiration benutzt der Angreifer alle Sessions bzw. Berechtigungen. Dies geschieht z.B. bei öffentlichen PC’s in einem Internetcafe. Sollte ein Benutzer sich bei Web-Applikationen die Session nicht beendet haben, z.B. Logout Button betätigt haben, dann kann die folgende Person dessen Session weiternutzen und auf die Daten, die die Webseite dem Benutzer zur Verfügung gestellt hat, zugreifen.[18]

5.1.8.3 Session Fixation

In diesem Fall wird die Session ID auf einen festen Wert gesetzt. Dazu können zum Beispiel Cross-Site Scripts genutzt werden, um die Session ID auf einen gewünschten Wert zu setzen. Sobald der Nutzer sich an der Web-Applikation anmeldet, kann der Angreifer die zuvor definierte Session ID nutzen.[19]

5.1.9 Insecure Communications

Die Daten werden unverschlüsselt bzw. schlecht verschlüsselt versendet. Somit hat ein Angreifer die Möglichkeit die Daten abzufangen und auszuwerten. Gerade bei sensiblen Daten ist dies ein enormes Sicherheitsrisiko. [20]

5.1.10 Failure to Restrict URL Access

Durch Ausprobieren, Brute Force, wird versucht auf Inhalte direkt zu zugreifen, ohne das die Inhalte verlinkt sind. Meistens werden Ordner oder Seiteninhalte nur geschützt, mit denen man direkt in Berührung kommt, wenn man die URL aufruft und welche Links von der Hauptseite abgehen. Jedoch haben Web Applikationen häufig ungeschützte Dateien, die durch einfaches ausprobieren geöffnet werden können.[21]

5.2 Statistiken

Abbildung 2: Statistik zu OWASP Top 10
Abbildung 2: Statistik zu OWASP Top 10[22]

Das Web Application Security Consortium hat 2008 eine Studie zum Thema Sicherheit von Web Applikationen veröffentlicht. Es wurden 12186 Web Applikationen auf ihre Schwachstellen geprüft. Dabei wurden insgesamt 97554 Sicherheitslücken gefunden. Des Weiteren sind ca. 52% aller geprüften Web Applikationen nicht „PCI DSS Standard“-konform. In der ersten Abbildung wird betrachtet, welche Angriffsmethoden am effektivsten sind. Das bedeutet z.B. bei Cross-Site Scripting, dass durchschnittlich 39% aller getesteten Web Applikationen mit Hilfe von Cross-Site Scripting angegriffen werden können und auch zum Erfolg führen. Danach folgt die Angriffsmethode Information Leakage mit 32%.[23]


Abbildung 3: Statistik zu PCI DSS Standard
Abbildung 3: Statistik zu PCI DSS Standard[24]

In derselben Studie wurden ebenfalls Statistiken zum PCI DSS Standard veröffentlicht. Wie viele Web Applikationen die Zahlungsverkehr Bestimmungen des PCI DSS Standards nicht nach kommen. Dabei ist heraus gekommen, dass ca. 48% der getesteten Web Applikationen nicht „PCI DSS Standard“-konform arbeiten.[25]




6 Fähigkeiten der Web-Applikation Firewall

6.1 Arten

Man unterscheidet bei WAFs drei Kategorien an Firewalls und zwar Hardware-Appliance, Module und nach Software. Hardware-Appliance basiert auf eigenständige Hardware Module, die in das Netzwerk eingebunden werden können. Des Weiteren bieten Hersteller eine Modullösung an. Diese Module werden für bereits genutzte Webserver hergestellt, um diese mit einer WAF Funktion zu erweitern. Zum Schluss gibt es noch Hersteller, die eine Softwarelösung vertreiben. All diese Arten haben ihre Vorteile, aber im Grunde kommt es darauf an, wie sie im bereits bestehenden Netzwerk eingebunden werden. Dies wird im folgenden Abschnitt behandelt. [26]

6.2 Struktur

Abbildung 4: Netzwerkstruktur mit WAF als Netzwerkmodul
Abbildung 4: Netzwerkstruktur mit WAF als Netzwerkmodul[27]

Es gibt drei verschiedene Arten eine WAF in ein Netzwerk einzubinden. Dazu gibt es die Möglichkeit die WAF, also einzelnes Netzwerkmodul, einzubinden ohne ihr weitere Funktionen in die Verantwortung zu übergeben. In diesem Fall würde die WAF hinter der Netzwerkfirewall als eigenständiges Element eingebunden. In diesem Fall müsste jedoch der komplette Datenstrom erst an die WAF weitergeleitet werden und nachdem die WAF die Daten geprüft hat, erfolgt erst die Übertragung zum Web- oder Datenbankserver. Des Weiteren müsste die WAF Kopien von SSL Schlüssel besitzen.





Abbildung 5: Netzwerkstruktur mit WAF als Proxy
Abbildung 5: Netzwerkstruktur mit WAF als Proxy[28]

Die zweite Möglichkeit ist, dass die WAF als Proxy im Netzwerk implementiert wird. Das bedeutet die WAF übernimmt die Proxy Funktionen des Netzwerkes und baut die Kommunikation mit dem Client auf. In diesem Fall wird die WAF in der DMZ implementiert und von zwei Netzwerkfirewalls umschlossen. Alle Daten werden dabei erst durch die WAF transportiert und nachdem diese erfolgreich geprüft wurden weiter zu dem Webserver oder zum Datenbankserver geleitet. Dies birgt die Gefahr eines Flaschenhalses, da sämtliche Transaktionen durch die WAF müssen. Um dem vorzubeugen, haben WAFs bereits weitere Aufgaben übernommen, indem sie z.B. als Load Balancer eingesetzt werden, sofern zwei parallele WAFs im Netzwerk integriert sind. Dennoch bedarf es eines hohen Aufwands das Netzwerk anzupassen.





Abbildung 6: Netzwerkstruktur mit WAF als Embedded
Abbildung 6: Netzwerkstruktur mit WAF als Embedded[29]

Die letzte Möglichkeit ist die sogenannte Embedded Version. In diesem Fall wird die WAF als Software auf dem Webserver selbst installiert werden. Damit nutzt er die Ressourcen des Webserver. Dennoch ist es einfach zu implementieren und ist sehr viel preiswerter, da keine Netzwerkanpassung stattfinden muss.[30]








6.3 Techniken

Abbildung 7: HTTP Traffic im Netzwerk
Abbildung 7: HTTP Traffic im Netzwerk[31]

Ein Hauptgrund, wieso Angriffe auf Web Applikationen so erfolgreich sind, ist das normale Netzwerkfirewalls diese Angriffe nicht erkennen können. Die Netzwerk Firewall-Systeme haben nicht die Möglichkeit den HTTP Traffic zu analysieren. Aus diesem Grund sind sie gegen Angriffe auf Web Applikationen chancenlos. Aus diesem Grund werden WAFs eingesetzt, die versuchen Sicherheitslücken von Web Applikationen zu schließen. Eine WAF arbeitet im OSI-Schichtenmodell auf der Schicht 7, der Applikationsschicht. [32] Die Hauptaufgabe der WAF besteht zum Einen in der Erkennung von Angriffen und zum Anderen sollen Sicherheitslücken mit Hilfe der WAF geschlossen werden. Zur Erkennung gibt es vier Methoden, die eine WAF unterstützen sollte. Zunächst müssen Daten normalisiert werden, das bedeutet die Daten werden decodiert und auf einzelne Bestandteile geprüft, z.B. Auswahlfelder oder Formulare der Web Applikation. Die nächste Methode ist das Negativ Sicherheitsmodell und ist auch als Blacklist bekannt.[33] Diese Methode nutzt eine Liste, in der hinterlegt ist, welche Verbindungen nicht auf die Web Applikation zugreifen dürfen. Alle anderen Verbindungen haben die Berechtigung auf die Web Applikation zuzugreifen. Eine WAF sollte jedoch nicht nur Blacklist unterstützen sondern auch Whitelist Methode. Dazu wird ebenfalls eine Liste mit Verbindungen erstellt, die grundsätzlich erlaubt sind. Dabei wird alles außer der, auf der Whitelist stehenden Verbindungen automatisch geblockt. Da kann es jedoch zu Problemen kommen, da jegliche Verbindung, die nicht explizit erlaubt wurde, keinen Zugriff auf die Applikation hat. Somit müssen die Regeln in der Whitelist äußerst sorgfältig geführt werden, da die Kunden/Nutzer weiterhin Zugriff auf die Web Applikation haben sollen. Beide Methoden vergleichen die Daten mit bereits bekannten Angriffsmethoden. Die beiden Sicherheitsmethoden werden meistens mit einem so genannten Lernmodus ausgestattet, der selbstständig Verbindungen analysiert und potenzielle Gefahren nach bestimmten Kriterien filtert und diese potenziellen Gefahren auf die Blacklist setzen bzw. von der Whitelist nehmen.[34]

6.4 Nutzen und Risiken

Der Nutzen von WAFs besteht darin, den Administratoren von Web Applikationen die Möglichkeit zu geben Sicherheitslücken zu schließen und Angreifern zu erschweren die Web Applikation anzugreifen. Dennoch reicht es nicht aus eine WAF in sein Netzwerk. WAFs müssen an die Eigenschaften des vorliegenden Netzwerkes angepasst werden und sehr viele Einstellungen sowie Policies erstellt werden. Die Einstellungen der WAFs müssen von geschulten Administratoren vorgenommen werden, da die Implementierung einer WAF in ein bestehendes Netz mit sehr viel Planungsaufwand verbunden ist. Bei einer Neuentwicklung von Web Applikationen kann man bereits vorsorglich Entscheidungen treffen, um die Sicherheitslücken bereits bei der Programmierung auszuschließen. Gerade bei Neuentwicklungen ist es jedoch sehr viel einfacher eine WAF einzubinden. Ein weiteres Problem ist, dass immer wieder neue Sicherheitslücken gefunden werden und somit die WAFs immer wieder auf neue Sicherheitslücken sensibilisiert werden müssen. Des Weiteren müssen die User / Benutzer oder Kunden auf Sicherheit sensibilisiert werden. WAFs können Sicherheitslücken schließen jedoch keine hundertprozentige Sicherheit bieten, da es immer eine Möglichkeit geben wird, durch neue Angriffsmethoden oder neue Sicherheitslücken sich auf irgendeine Weise Zugriff zu Web Applikationen zu verschaffen. Des Weiteren ist nur ein komplettes Sicherheitspaket ein nahe zu sicherer Schutz. Das bedeutet, dass Netzwerke aus einer Kombination mehrerer Sicherheitssysteme geschützt werden müssen, z.B. Netzwerkfirewall, Applikation Firewall und eben Web Applikationen Firewall. Zu guter Letzt muss man den Wirtschaftlichkeitsfaktor betrachten, ob es sich lohnt eine Web Applikation ausreichend zu schützen, wenn sie nur wenig bzw. nicht genug Profit erwirtschaftet.[35][36]

6.5 Einsatz einer Web Applikation Firewall

In diesem Abschnitt sollen zu den zu Beginn erläuterten Angriffsszenarien Lösungsvorschläge gemacht werden. Ferner soll gezeigt werden, welche Hilfeeine WAF zur Sicherung dieser Angriffe bietet. Dazu wurden die Top 10 der OWASP betrachtet.[37]

6.5.1 Cross-Site Scripting

WAF ermöglicht in diesem Fall keine Ausgabevalidierung, da sie den Kontext der Daten nicht kennt. Die Validierung muss schon bei der Eingabe erfolgen und kann eventuell mit der Ausgabe korreliert werden.[38]

6.5.2 Injection Flaws

Um Web Applikationen vor Injection Flaws zu schützen, setzen WAFs auf Black- und Whitelist Methode. Bei der Blacklist kann nur nach bestimmten Zeichen oder Zeichenketten gefiltert werden und die Verarbeitung vermeiden. Dies ist jedoch nur bei bereits bekannten Angriffen möglich, da die Syntax bzw. die Angriffssyntax bekannt sein muss, um nach diesen Filtern zu können. Bei dem Verfahren mit Whitelist werden für alle Eingabefelder nach einer Lernphase einzelne Felder erlaubte Einträge vorgegeben.[39]

6.5.3 Malicious File Execution

Erstellen einer Whitelist, die die Parameter der für das Einbinden fremder URL’s erlauben. Durch eine Responseanalyse wird das Anzeigen von kritischen Daten verhindert.[40]


6.5.4 Cross-Site Request Forgery (CSRF)

Kann mit Hilfe von URL-Encryption gelöst werden. Ein Beispiel für URL-Encryption. Anwendung sendet HTML mit Klartext-URLs:
http://192.168.1.123/news.php?include=news.php
Browser erhält verschlüsselte URL:
https://www.myapp.demo/$xp1/GMnGuYqPtCSYMQqnWFTb [41]

6.5.5 Information Leakage

Kommentare werden auskommentiert und der Zugriff auf nicht öffentliche Daten wird verweigert. [42]

6.5.6 Broken Authentication

Die WAF hat die Möglichkeit unabhängig von der Web Applikation eine Authentisierung vorzunehmen Und somit ohne Änderungen an der Applikation eine Anbindung an eine zentrale Authentisierungsinfrastruktur zu ermöglichen. [43]

6.5.7 Session Management

Verbesserung des Sessions-Management durch z.B. Page Token. Page Token ist eine Technik, die anstatt die URL mit Variablen nur noch mit Zufallszahlen anzeigt (der Page Token). Der Server verknüpft dann die URL mit der Zufallszahl. Wenn der Nutzer einen Link betätigt, validiert der Server den Page Token mit der zuvor verknüpften Session. [44]

6.5.8 Insecure Communications

Eine WAF hat die Möglichkeit HTTP mit HTTPS abzusichern. [45]

6.5.9 Failure to Restrict URL Access

Benutzer kann mittels Page-Token oder URL Encryption auf Seiten eingeschränkt werden, die er von der Anwendung als Link erhält. Die Anwendung darf hierzu allerdings geschützte Links nicht anzeigen. Auch können bestimmte URLs/Teilbäume durch Whitelist/Blacklist Ansätze ausgeschlossen werden (z. B. allow access nur für *.html, *.php, *.gif, *.jpg – aber nicht für .bak oder andere Extensions). [46]

7 Marktübersicht

7.1 Hardware-Appliance

Unter Hardware-Appliance versteht man eigenständige Hardware Module, die mit entsprechenden Netzwerkkarten sowie eigener Stromquelle ausgerüstet sind. Diese eigenständige Hardware wird von den Herstellern oft mit weiteren Netzwerkfeatures verbunden, z.B. mit Proxy Funktionen oder als Loadbalancer. Diese Hardwaremodule stellen Netzwerkspezialisten wie Cisco, Citrix, Baracuda und F5 zur Verfügung und sind damit marktführend, da gerade im kommerziellen Bereich sehr viele Firmen auf einheitliche Netzwerkstrukturen setzen und somit möglichst alle Netzwerkelemente von einem Hersteller nutzen. Gerade Cisco, die den Unternehmen Funktionen zur Verfügung stellen, die nur mit Cisco-Geräten unterstützt werden. [47][48]

7.2 Module

Hier werden Softwarelösungen für bestimmte Komponenten vertrieben, z.B. gibt es Lösungen, die in bestehenden Webserver wie Apache integriert werden können. Des Weiteren gibt es Lösungen wo die Module in Loadbalancern integriert werden können. Diese Modulhersteller vertreiben ihre Lösungen in Kooperation mit Herstellern anderer Netzwerkkomponenten bzw. bieten Lösungen für Webserver Software an, z.B. bietet HP eine Hardware-Appliance Lösungen an, die jedoch mit einem Softwaremodul von „Art of defence“ bestückt ist. Art of defence vertreibt die WAF Modullösung für verschiedene Webserver und Hardware Komponenten.[49]

7.3 Software

Es gibt einige weniger WAF Hersteller, die auf Softwarelösungen setzen. Diese Software wird häufig auf Webservern auf denen die Web Applikation selber läuft installiert. Daher ist eine Umstrukturierung des Netzwerkes für die Administratoren nicht von Nöten bzw. sie würde nicht viel Konfigurationsaufwand bedeuten. Ebenfalls können diese Arten von WAFs schnell in bereits bestehenden Netzwerklösungen integriert werden. Bekannte Hersteller für Software WAFs sind z.B. „protegrity“.[50]

8 Fazit

Es gibt keine vollkommene Sicherheit. Dennoch sollte man es Angreifern so schwer wie möglich machen. Aus diesem Grund sollten Web Applikationen gerade mit sensiblen Daten mit WAFs geschützt werden. Die Hauptschwachstelle in den Systemen ist weiterhin der Mensch. Die meisten Sicherheitslücken entstehen durch Fehler, aus gelöst durch Unkenntnis bzw. nicht genug sensibilisiert für Sicherheit. Aus diesem Grund sollten Unternehmen die Web Applikationen für profitable Einsätze Nutzen ihre Mitarbeiter auf dieses Thema schulen. Ebenfalls muss man den Kosten-Nutzen Faktor sehen.

9 Glossar

9.1 Web Applikation

Web-Applikationen sind Programme, die auf einem Web Server ausgeführt werden. Dabei interagiert der User mit dem Webserver.[51]

9.2 Firewall

Als Firewall werden alle Schutzmaßnahmen bezeichnet, die einen unerlaubten Zugriff von außen auf ein privates Netzwerk verhindern. Die grundsätzliche Schutzfunktion von einer Firewall ist das Blockieren von Kommunikationsdaten zwischen den Netzen, wenn bestimmte festgelegte Sicherheitskriterien verletzt werden.[52]

9.3 HTTP

http steht für Hypertext Transport Protocol, es wird als zentrales Übertragungsverfahren im Internet genutzt. Es überträgt alle vorhanden Datenformen im Internet. Der für das Protokoll genutzte Port ist 80. Des Weiteren gibt es eine verschlüsselte Version von http. Diese wird https genannt, wobei das „s“ für „secure“ steht. Https arbeitet mit Port 443.[53]

10 Fußnoten

  1. ↑ OWASP (2008), Seite 2
  2. ↑ Vgl. BSI (2009), Seite 37ff
  3. ↑ Westermann (2007), Seite 281
  4. ↑ ELKO (2009)
  5. ↑ Westermann (2007), Seite 290
  6. ↑ Vgl. Westermann (2007), Seite 290
  7. ↑ eCommerce-Special (2009), Seite 7
  8. ↑ Vgl. OWASP (2008), Seite 13
  9. ↑ Vgl. Web Application Security Consortium (2004), Seite 24
  10. ↑ Vgl. Web Application Security Consortium (2004), Seite 35
  11. ↑ Vgl. Web Application Security Consortium (2004), Seite 39
  12. ↑ Vgl. OWASP (2009)
  13. ↑ Vgl. OWASP (2009)
  14. ↑ Vgl. OWASP (2009)
  15. ↑ Vgl. Web Application Security Consortium (2004), Seite 45
  16. ↑ Vgl. Web Application Security Consortium (2004), Seite 12
  17. ↑ Vgl. Web Application Security Consortium (2004), Seite 15
  18. ↑ Vgl. Web Application Security Consortium (2004), Seite 17
  19. ↑ Vgl. Web Application Security Consortium (2004), Seite 19
  20. ↑ Vgl. OWASP (2009)
  21. ↑ Vgl. OWASP (2009)
  22. ↑ Web Application Security Consortium (2008), Seite 5
  23. ↑ Vgl. Web Application Security Consortium (2008), Seite 4ff
  24. ↑ Web Application Security Consortium (2008), Seite 17
  25. ↑ Vgl. Web Application Security Consortium (2008), Seite 17
  26. ↑ Marx (2009), Seite 12
  27. ↑ Vgl. OWASP (2006), Seite 28
  28. ↑ Vgl. OWASP (2006), Seite 29.
  29. ↑ Vgl. OWASP (2006), Seite 30
  30. ↑ Vgl. OWASP (2006), Seite 27ff.
  31. ↑ Vgl. OWASP (2006), Seite 4
  32. ↑ Vgl. OWASP (2006), Seite 8ff
  33. ↑ Vgl. OWSAP (2008), Seite 11
  34. ↑ Vgl. Marx (2009), Seite 11
  35. ↑ Vgl. OWASP (2008), Seite 12
  36. ↑ Vgl. Circosec (2009)
  37. ↑ Vgl. OWASP (2008), Seite 13ff
  38. ↑ Vgl. OWASP (2008), Seite 13
  39. ↑ Vgl. OWASP (2008), Seite 13f
  40. ↑ Vgl. OWASP (2008), Seite 14
  41. ↑ Visonys 2008, Seite 17
  42. ↑ Vgl. OWASP (2008), Seite 15
  43. ↑ Vgl. OWASP (2008), Seite 15
  44. ↑ Vgl. OWASP (2008), Seite 15f
  45. ↑ Vgl. OWASP (2008), Seite 16
  46. ↑ OWASP (2008), Seite 16
  47. ↑ Vgl. F5 (2009)
  48. ↑ Vgl. Barracuda (2009)
  49. ↑ Vgl. Art of Defence (2009)
  50. ↑ Vgl. Protegrity (2009)
  51. ↑ Vgl. Westermann (2007), Seite 281
  52. ↑ Westermann (2007), Seite 361
  53. ↑ Vgl. Westermann (2007), Seite 281

11 Quellen- und Literaturverzeichnis

Monographien

eCommerce-Special (2009) eCommerce-Special (Hrsg): PCI: Der richtige Umgang mit Kreditkartendate, August 2009, ISBN: 978-3-940416-14-8
Westermann (2007) Westermann (Hrsg): IT-Handbuch (Tabellenbuch) 5. Auflage, 2007, ISBN: 978-3-14-225042-7

Internet

OWASP (2008) OWASP (Hrsg): Best Practices:Einsatz von Web Application Firewalls, März 2008, http://www.owasp.org/images/1/1b/Best_Practices_Guide_WAF.pdf (22.01.2010)
OWASP (2009) OWASP,2009, http://www.owasp.org/index.php/Category:Vulnerability (20.01.2010)
OWASP (2006) Ivan Ristic: Web Application Firewalls: - When Are They Useful?, May 2006, http://www.owasp.org/images/9/9c/OWASPAppSecEU2006_WAFs_WhenAreTheyUseful.ppt (12.01.2010)
Web Application Security Consortium (2006) Web Application Security Consortium (Hrsg): Web Application Firewall Evaluation Criteria, Januar 2006, http://projects.webappsec.org/f/wasc-wafec-v1.0.pdf (21.01.2010)
Web Application Security Consortium (2004) Web Application Security Consortium (Hrsg): Web Application Security Consortium: Threat Classification, 2004, http://projects.webappsec.org/Threat-Classification-Previous-Versions (21.01.2010)
Web Application Security Consortium (2008) Web Application Security Consortium (Hrsg): Web Application Security Statistics 2008, 2008, http://projects.webappsec.org/f/WASS-SS-2008.pdf (26.12.2009)
Circosec (2009) Stefan Strobel: Gefahren und Möglichkeiten zur Absicherung von Web-Shops, ohne Jahresangabe, http://www.cirosec.de/deutsch/presse/veroeffentlichungen/webshops.html (26.12.2009)
Marx (2009) Stefan Marx: Web Application Firewalls in der Praxis, Juni 2009, http://www.computerwoche.de/security/1899003/ (26.12.2009)
BSI (2009) Bundesamtes für Sicherheit in der Informationstechnik (Hrsg): Die Lage der IT-Sicherheit in Deutschland 2009, Januar 2009, https://www.bsi.bund.de/cae/servlet/contentblob/476182/publicationFile/30725/Lagebericht2009_pdf.pdf
Protegrity (2009) Protegrity, http://www.protegrity.com/WebApplicationFirewall (20.01.2010)
Art of defence (2009) Art of Defence, http://www.artofdefence.com/de/hyperguard/hyperguard.html (20.01.2010)
Baracuda (2009) Baracuda Networks, http://www.barracudanetworks.com/ns/products/web-site-firewall-overview.php (20.01.2010)
F5 (2009) F5 Networks, http://www.f5.com/solutions/security/web-application/ (20.01.2010)
Visonys (2008) Daniel Estermann:Kombinierter Schutz für Web Applikationen,2008, http://www.security-zone.info/download/kongress08//N5/D_Estermann.pdf (20.01.2010)
ELKO (2009) elektronik-kompendium, 2009, http://www.elektronik-kompendium.de/sites/net/0904131.htm (24.01.2010)
Von „http://winfwiki.wi-fom.de/index.php/Web-Applikationen_Firewall_-_Grundlagen_und_Markt%C3%BCbersicht“
Persönliche Werkzeuge