Webshops stehen unter hartem Wettbewerb. Neben attraktiven Artikeln und Preisen heißt das: Wer hat den komfortabelsten Shop mit der schärfsten Optik und ist zugleich sicher.

In Zeiten, da die Nutzung gekaufter Frameworks (SAP, Oracle Suites) Standard ist und Entwickler aufgrund minimaler Entwicklungszeitfenster zunehmend auf Composites und Mashups zurückgreifen, wächst die Komplexität.

Umfangreiche Qualitätskontrollen in Form von Code Reviews werden nicht in jedem Releasezyklus mit dem gleichen Aufwand betrieben oder sind gar nur graue Theorie.

Hohe Komplexität und massiver Zeitdruck stehen gegen Qualität und Sicherheit.

Im Falle eines Angriffs drohen neben dem wirtschaftlichen Schaden und dem Imageverlust auch rechtliche Konsequenzen, denn seit dem 30. 09.2007 müssen Webshop-Besitzer, News-Portale, Finanzseiten und alle Unternehmen, die Kreditkarten-Daten speichern, übermitteln oder abwickeln, zwingend die Richtlinien des Sicherheitsstandards der Kreditkartenindustrie (PCI DSS) einhalten.

Bei Verstößen gegen den Regelkatalog kann es teuer werden: Je nach Umsatzvolumen werden Strafen verhängt, Einschränkungen ausgesprochen oder sogar die Annahme von Kreditkarten untersagt. Der Schutz der Web-Anwendungsebene (PCI 1.1) ist derzeit noch eine Best-Practice-Empfehlung, ab 1. Juli 2008 wird er jedoch verpflichtend.

PCI Security Standards Council

Ein hohes, PCI-konformes Sicherheitsniveau für Webapplikationen auch unter schwierigen Entwicklungsbedingungen zu erzielen, das ermöglichen Ihnen Web Application Firewalls, kurz WAF.

Klassische Sicherheitslösungen - wie Firewalls, Reverse Proxies, Deep Inspection und IDS/IPS - können Webapplikationen nur sehr rudimentär schützen, da sie den Verkehr auf Transportschichten absichern und allenfalls eine einfache Mustererkennung ermöglichen, aber den Business Logik Layer nicht interpretieren können. Typische Angriffe gegen Webapplikation, wie Form Filed Tampering, SQL Injections, Parameter Manipulationen, Cross Site Request Forgery, Brute Force Login, Cookie Poisoning oder Session Highjacking werden somit nicht erkannt; eine Analyse der Requests auf HTTP- und Business Logik Ebene findet nicht statt.

Informieren Sie sich bezüglich dieser Thematik beim Web Application Security Consortium

Hochentwickelte Web Application Firewalls (WAF) hingegen beherrschen alle Protokoll-Ebenen und filtern bekannte und unbekannte Angriffe gegen transaktionsorientierte Webanwendungen. Das schließt auch neue Angriffsarten gegen die Web 2.0-Technologie, wie Cross-Site Request Forgery oder Malicious AJAX Code Execution ein.

Dazu werden eingehende HTTP-/ HTTPS-Requests entgegengenommen, analysiert (Mustererkennung, statistische Methoden) und klassifiziert (legitim, Angriff, verdächtig), bevor Sie die Webapplikation erreichen.

Die gängigsten Verfahren der Request Verfication sind:

1. Protokoll-Terminierung, Validierung und Rebuilding
2. Session Tracking & Anomaly Detection
3. SSL-Terminierung und Absicherung der Session- und Cookie-Handlings
4. Input Validation zur Prüfung von Benutzereingaben / Abfangen von Command-Injections
5. Malicious Code Detection / Schadcodeerkennung durch Muster- und Anomalie-Detektion
6. Phishing Detection / Referer Checking zur Unterbindung von unerwünschten Verlinkungen

Eine der Kernaufgaben einer WAF ist es, zu gewährleisten, dass nur URL-Aufrufe, die zur Anwendung gehören, zugelassen werden.

Andersherum gesagt: Ressource-Zugriffe unterhalb der Webserver-Wurzel, z.B. auf DLLs, Dateiversionen oder gar interne Anwendungen müssen abgefangen werden.

Doch woher weiß die WAF, was gut und richtig ist?

Moderne Lösungen können dynamisch zur Laufzeit lernen. Nach dem Aufruf einer erlaubten Start-URL analysiert die WAF alle vom Webserver zurückgelieferten Webseiten und fügt deren URLs der dynamischen Policy hinzu, die sie im Hauptspeicher hält. Das Problem: Nicht gelernte URLs bockiert sie und somit auch alle verlinkten URLs, die noch nicht aufgerufen wurden. URL-Crawler, die alle Links verfolgen, können hier Abhilfe schaffen.

In der Praxis hat sich die Kombination aus statischer Start-Policy und dynamischem Lernen als sehr brauchbar erwiesen. Von Sicherheitslösungen, die rein statisch arbeiten, wie z. B.  das quelloffene Tool mod-security für den Apache Webserver, ist aufgrund ihrer unzureichenden Angriffsabdeckung und dem immensem Betriebsaufwand eher abzuraten.

Eine weitere zentrale Aufgabe einer WAF ist Input Validation. Weil das größte Angriffspotenzial in Injection-Angriffen (SQL- / Command- Injections, Cross Site Scripting) liegt, müssen Parameterkontrollen (Session IDs, Wertebereiche) exakt ausgeführt werden. Wert und Länge jedes einzelnen Parameters der Webanwendung individuell in der WAF zu konfigurieren - noch dazu - wenn häufige Änderungen in der Anwendung die Regel sind, grenzt an Sisyphos-Arbeit. Gute Lösungen bieten hierfür Blacklists, die sämtliche Arten von Injection-Angriffen adressieren und zeitnah aktualisiert werden.

Neben der Kontrolle der Benutzereingaben muss die WAF aber auch deren Integrität der Read-Only-Parameter prüfen. Das funktioniert am besten dynamisch, indem sich die WAF zur Laufzeit der Session die Werte der von der Applikation erstmals an den User ausgelieferten Parameter merkt.

Interessiert an einem fundierten Fachgespräch und Lösungen für konkrete Anforderungen? Dann kommen Sie ruhig etwas näher und sprechen Sie uns an.