Web application security

Web Application Security

Oliver Hader Aktuelle Themen zur Sicherheit im Web

Studiengang Master Internet Web Hochschule Hof

[email protected]

ZUSAMMENFASSUNG Die Zahl von unerlaubten Cyber-Aktivitäten hat in den letzten Jahren stark zugenommen. Viele Teilaspekte des täglichen Lebens werden im privaten und beruflichen Umfeld inzwischen überwiegend über Web-Technologien gehandhabt. Angriffsversuche auf diese Anwendungen und die bereitgestellten Informationen finden im Alltag automatisiert statt. Es gibt jedoch einige grundlegende Maßnahmen, um die Verwundbarkeit von Web Applikationen zu reduzieren, welche bereits bei der Konzeption und Entwicklung berücksichtigt werden sollten. Da sich Bedrohungsszenarien ändern und sich die jeweils angewandte Methodik weiterentwickelt, ist der Begriff „Sicherheit“ im Allgemeinen jedoch als fortlaufender Prozess anzusehen.

Categories and Subject Descriptors D.2.4 [Software/Program Verification]: Validation techniques to ensure reliability of user-submitted information of models H.2.0 [General]: Security, integrity and protection of databases

H.3.5 [Online Information Systems]: Security attack vectors and mechanisms of web-based service

K.6.5 [Security and Protection]: Unauthorized access using hacking and hijacking approaches to retrieve or manipulate confidential information

General Terms Reliability, Security, Theory, Verification

Keywords Hacking, SQL Injection, Cross Site Scripting, Techniques, Awareness, Indication

1. Motivation Eine eigene Internet-Präsenz ist für Privatpersonen relativ einfach in Betrieb zu nehmen. Hosting-Dienstleister, die vornehmlich die Masse bedienen, bieten Hilfsmittel an, um mit einigen Klicks und zusätzlichen Angaben z.B. eine Blog-Anwendung auf der eigenen Internet-Domain einzurichten. Im Rahmen des Social Media Zeitalters gehören somit auch Kommentare und weitere Interaktionsmöglichkeiten zum Standardumfang von Web-Anwendungen. Informationen können so von beliebigen Internet-Nutzern empfangen, gespeichert und für wieder andere ausgegeben und dargestellt werden.

Bei gewerblichen oder behördlichen Auftritten im Internet verschiebt sich dieser Fokus auf offizielle Informationen, wie Produkte, Preise oder Pressemitteilungen, welche sowohl für Jedermann öffentlich zugänglich als auch nur für eine vorgegebene Benutzergruppe geschützt einsehbar sind.

Versuche, auf diese Daten unberechtigt zuzugreifen oder gar zu manipulieren, gehören inzwischen zum Alltag. Von außen werden

willkürlich Schwachstellen von Internet-Anwendungen automatisiert analysiert, gesammelt und bei Erfolg für gezielte Angriffe zu einem späteren Zeitpunkt verwendet.

Neben einer durchdachten und abgestuften Sicherheitsstrategie für Infrastruktur, Netzwerkkomponenten, Betriebssystem und verarbeitenden Web-Server, sind auch besondere Anforderungen an den Aufbau und Umfang von Applikationen hinsichtlich von Sicherheitsmechanismen gestellt. Die Bedeutung und Gültigkeit von Informationen, kann schließlich nur innerhalb eines konkreten Anwendungskontexts bewerten werden.

2. Gefährdungslage

Abbildung 1: OWASP Gefährdungen für 2010 und 2013

Das Open Web Application Security Project (OWASP) bewertet und veröffentlicht jährlich die häufigsten Sicherheitsgefahren [1]. Neben der Möglichkeit, generell unberechtigt Daten in eine Applikation einzuschleusen, sind auch unzureichende Authentifizierungsmechanismen, sowie die Verteilung von Malware über einen Internet-Auftritt innerhalb der letzten vier Jahre unter den ersten Plätzen der OWASP Erhebung zu finden.

Für den Betreiber einer Web-Site spielen die Aspekte Vertraulichkeit (engl. Confidentiality), Integrität (engl. Integrity) und Verfügbarkeit (engl. Availability) eine zentrale Rolle [2]. Auf Informationen, die als vertraulich eingestuft sind, darf somit nur von Berechtigten, unter Verwendung von geeigneten Legitimationsverfahren, zugegriffen werden – persönliche Daten der digitalen Privatsphäre zählen ebenfalls dazu. Im Sinne der Integrität sind Informationen, welche als vertrauenswürdig eingestuft werden, gegen unerlaubte Manipulation oder Löschung zu sichern. Durch Überlastung des Systems bewusst herbeigeführte Ausfallzeiten beeinträchtigen die generelle Nutzbarkeit eines Internet-Angebots und adressieren die Aspekte der Verfügbarkeit.

3. ANGRIFFSVEKTOREN Angriffe auf Internet Anwendungen können über verschiedene technische Methoden durchgeführt werden. Grundsätzlich gibt es

jedoch auch dafür einige grundlegende Prinzipien, um entsprechende Gegenmaßnahmen ergreifen zu können.

3.1 Methoden 3.1.1 HTTP Header Bei jedem Aufruf einer Internet-Adresse über den Browser wird eine HTTP Anfrage an den Server übermittelt. Über den gesendeten HTTP Header werden die angefragten Informationen konkretisiert. Diese Anfragen können jedoch auch mühelos außerhalb eines Browsers manipuliert und mit gefälschten Daten angereichert werden.

Ein Angriffspunkt ist der Host Header – vornehmlich bei Internet-Auftritten, welche, zusätzlich zu einem Domainnamen, direkt über eine IP-Adresse erreichbar sind. Voraussetzung für einen erfolgreichen Angriff ist jedoch die Verwendung dieses gefälschten Host Namens innerhalb der Anwendung, z.B. um eine absolute URL unter Einbeziehung des Domainnamens zu erzeugen – dieser wird nämlich aus dem Host Header abgeleitet.

Bedingt durch die Zustandslosigkeit des HTTP Protokolls, müssen Informationen zur aktuellen Benutzer-Sitzung (Session) mit jeder Anfrage über einen Cookie Header an den Server übertragen werden. Genau dieser Umstand bietet eine weitere Angriffsmöglichkeit, um eine bestehende Sitzung zu übernehmen und somit Zugriff zu einem geschützten Benutzerbereich zu bekommen.

3.1.2 Query Parameter Query Parameter können beliebige Informationen beinhalten und werden von der entsprechenden Anwendung generiert und ausgewertet. Beispielsweise sind dies Referenzen auf eine bestimmte Seite oder eine Produktnummer, die dem Benutzer angezeigt werden soll.

Sicherheitsrelevante Schwachstellen ergeben sich durch eine ungeprüfte Weiterverwendung dieser Daten, sowie durch die Speicherung und identische Ausgabe auf der Internet-Präsenz.

3.1.3 Dateien Durch die Möglichkeit, Dateien auf ein Server-System zu übertragen eröffnen sich weitere Angriffspunkte. So könnten beispielsweise in einer Anwendung neben den ursprünglich vorgesehenen Bildern auch ausführbare Dateien übermittelt und abgespeichert werden. Kann der Angreifer ermitteln, wo diese Daten abgelegt werden und ob diese über der Internet aufrufbar sind, ergibt sich daraus die Möglichkeit, ein Admin-Tool einzuschleusen und Kommandos direkt auf dem System auszuführen.

3.1.4 Systeme Bei der Entwicklung von Systemen kommen bevorzugt wiederverwertbare Bibliotheken von Dritten zum Einsatz, deren Entwicklungsverläufe, bedingt durch den Umfang und die Änderungshäufigkeit, nicht oder nur begrenzt geprüft werden können. Bei Vorliegen der Verwundbarkeit von einer dieser externen Komponenten, ist somit automatisch auch der komplette Wirkungsbereich einer Anwendung betroffen und insgesamt als unsicher einzustufen.

Darüber hinaus erfordert die zunehmende Abstraktion und Komplexität von Systemen einen detaillierten Kenntnisstand über die Einsatz- und Konfigurationsmöglichkeiten, sowie generell ein grundlegendes Sicherheitsbewusstsein. Die Erwartungshaltung, externe Komponenten würden den Sicherheitsanforderungen

entsprechen, erweist sich ohne weitere individuelle Prüfung als trügerisch [3][4].

Sicherheitslücken in Open Source Software werden bei Bekanntwerden zwar rasch behoben und durch eine neue Veröffentlichung des jeweiligen Produkts beseitigt. Jedoch führt diese Offenheit des Quellcodes auch dazu, dass Schwachstellen von potenziellen Angreifern schneller analysiert und ausgenutzt werden können.

3.2 Prinzipien & Maßnahmen Sicherheitsvorkehrungen und Mechanismen sind grundsätzlich individuell auf den Kontext der Anwendung abzustimmen. Es gibt jedoch im Allgemeinen auch einige grundlegende Maßnahmen, um das Sicherheitsrisiko zu minimieren. So ist auch bei Web Anwendungen davon auszugehen, dass jede Transaktion oder Anfrage auch einen potenziellen Angriff auf die Sicherheit darstellt. Somit sind auch alle übermittelten Daten vorerst als nicht vertrauenswürdig einzustufen. Dieser Blickwinkel ist so lange gültig, bis das Gegenteil ermittelt und bewiesen werden kann.

Bei der Bewertung von Zulässigkeiten existieren die Begriffe Blacklisting (nur bekannte, ungültige Aspekte verweigern) und Whitelisting (nur bekannte, gültige Aspekte akzeptieren). Unter Anwendung der vorher genannten paranoiden Grundannahme, ist also die Methodik des Whitelistings zu bevorzugen, da das Blacklisting mitunter nicht vollständig ist und potenzielle Angriffe unerkannt bleiben würden.

3.2.1 Validation & Filtering Bei übermittelten Daten sind folgende Überprüfungen notwendig:

• Datentyp: z.B. Prüfung auf Integer-Wert • Format: z.B. Prüfung auf gültige E-Mail Adresse • Länge: z.B. Prüfung der minimalen/maximalen Länge • Inhalt: z.B. Prüfung des MIME Typs bei Dateien

Diese Maßnahmen dienen zum Schutz von nachfolgenden, verarbeitenden Komponenten. Bei ungültigen Daten sind die betroffenen Bestandteile auszufiltern. Falls dies nicht möglich ist, ist die Verarbeitung komplett abzubrechen – bedarfsweise mit einer entsprechenden Fehlermeldung an den Anwender.

3.2.2 Escaping Benutzereingaben werden in der Regel auch weiterverarbeitet und beispielsweise zur Speicherung an ein Datenbanksystem geleitet, oder auch als Parameter an Systemaufrufe delegiert. Um die Schädlichkeit von eingeschleusten Parametern zu entschärfen, müssen Steueranweisungen, je nach Verarbeitungskontext, erweitert werden. Meistens ist es ausreichend, Steueranweisungen einen Backslash (\) als Escape-Sequenz voranzustellen, um das entsprechende Literal als herkömmliches, bedeutungsloses Zeichen zu markieren.

Tabelle 1: Steueranweisungen nach Verarbeitungskontext

Kontext Steueranweisungen

Datenbank/SQL " ' % _ \

Systemaufruf/CLI # & ; ` | * ? ~ ^ <> () [] {} $ \ \x0A \xFF

3.2.3 Encoding Beim Einsatz von Formularen wird einem einzelnen Benutzer die Möglichkeit gegeben, Daten an eine Anwendung zu übermitteln, welche nach einer Verarbeitung wieder ausgegeben werden. Bei Kommentarfunktionen werden diese Informationen gespeichert und somit auch anderen Nutzern einer Internet-Seite dargestellt. Die Ausgabe erfolgt dann hauptsächlich über HTML oder JavaScript. Um zu verhindern, dass Literale mit darstellungsspezifischer Semantik missbräuchlich eingeschleust werden, sind diese Bestandteile entsprechend zu kodieren.

Tabelle 2: Semantische Literale nach Darstellungskontext

Kontext Literale mit Semantik

XML/HTML < > " ' &

JavaScript < > " ' & ! \ {SPC} {LF} {CR} {TAB}

Betroffene Zeichen für die Verwendung in XML/HTML werden in ihre Entitäten bzw. in JavaScript in eine Unicode-Notation überführt. Diese Unterscheidung ist notwendig, da die Maßnahmen für XML/HTML nur einen Teilbereich bei JavaScript absichern würden.

Tabelle 3: Beispiele für Kodierung von Literalen

Kontext Literal Kodierung

XML/HTML < <

XML/HTML & &

JavaScript < \u003C

JavaScript {TAB} \u0009

3.3 Szenarien Die nachfolgenden Angriffsszenarien kombinieren die Aspekte der generellen Angriffsmethoden und Gegenmaßnahmen für einen bestimmten technischen Anwendungsbereich.

3.3.1 SQL Injection Beim Einschleusen von Anweisungen über Parameter in SQL Anfragen werden fehlende oder fehlerhafte Schritte hinsichtlich Validierung und Escaping ausgenutzt. Neben dem Oberbegriff SQL Injection wird zusätzlich in Blind Injection, Time-based Injection und Code Injection unterschieden. Bei einem „blinden Angriff“ werden keine offensichtlich geänderten Resultate oder Fehlermeldungen ausgegeben – lediglich durch Details, wie z.B. eine längere Verarbeitungsdauer, kann auf das erfolgreiche Einschleusen von Anweisungen geschlossen werden [5].

Im folgenden Beispiel wird eine SQL Anweisung innerhalb einer PHP Anwendung mit dem Query-Parameter productId zusammengesetzt. Anhand dieser Ausgangssituation werden weitere Angriffsvarianten erklärt. <?php $connection = new \PDO(); $query = 'SELECT id, title FROM products' . ' WHERE id=' . $GET['productId'] . ' AND hidden=0;'; $connection->query($query);

Abbildung 2: Beispiel zum Erzeugen einer SQL Anweisung

Die erwartungsgemäß auszuführende SQL Anweisung sähe folgendermaßen aus, wenn für den productId Parameter unter Normalbedingungen ein ganzzahliger Wert – hier der Wert 13 – übermittelt worden wäre. SELECT id, title FROM products WHERE id=13 AND hidden=0;

Abbildung 3: Resultierende SQL Anweisung

Für den productId Parameter können nun jedoch auch beliebige andere SQL Anweisungen übergeben und eingeschleust werden. Es sei angemerkt das zwei Minuszeichen (--) in SQL eine Steueranweisung darstellen und den Beginn eines Kommentars einleiten – Anweisungen und Zeichen nach diesem Kommentarbeginn würden also komplett vernachlässigt und nicht ausgeführt werden. Angriffsmöglichkeiten für den productId Parameter:

• Auswahl aller Produkte 1 AND 0=1; --

• Löschen von Datensätzen einer anderen Tabelle 1; DELETE * FROM users; --

• Zusammenführen und Überladen von Werten 1 AND 0=1 UNION SELECT users.username, users.password FROM users; --

• Zeitbasierter Angriff (time-based blind injection) 1 OR BENCHMARK(1000000, SHA1(id)); --

• Schreiben einer Datei mit Quellcode (code injection) 1; SELECT '<?php phpinfo();' INTO OUTFILE '/var/www/phpinfo.php'; --

Wirksame Gegenmaßen sind einerseits sinnvolle Validierungsmaßnahmen – wird für die Auswahl eines Produkts einer Produkt-Nummer als Integer-Wert erwartet, so ist vorab sicherzustellen, dass auch nur ein gültiger Wert an das Datenbanksystem weitergeleitet wird. Zusätzlich könnte in diesem Fall der Eingabewert auch explizit in einen Integer-Wert transformiert werden (explicit type cast). Bei Zeichenketten ist es notwendig, mögliche Steueranweisungen zu entschärfen (escaping). Bevorzugt wird aber die Verwendung von Prepared Statements empfohlen, welche automatisch und implizit die Grenzen der Parameter wahren und das Einschleusen von schadhaften Befehlen so ausschließen [6]. <?php $connection = new \PDO(); $query = 'SELECT id, title FROM products' . ' WHERE id=:productId AND hidden=0;'; $statement = $connection->prepare($query); $statement->execute([ 'productId' => $GET['productId'] ]);

Abbildung 4: Beispiel zum Erzeugen einer sicheren SQL Anweisung unter Verwendung von Prepared Statements

3.3.2 Cross Site Scripting (XSS) Dieses Verfahren bezieht sich auf das Einschleusen von schädlichen Informationen in einen eigentlich vertrauenswürdigen Anwendungskontext. Die Gefahr besteht darin, dass dieser Schadcode abgespeichert wird und somit auch an andere Benutzer beim Aufruf der Internet-Seite weitergegeben wird.

Mittels JavaScript ist es möglich, weitere externe Programme hinzuzuladen und so z.B. Benutzereingaben im Browser zu

protokollieren oder die Identität und Berechtigungen innerhalb einer Benutzer-Sitzung auszunutzen, um Informationen zu manipulieren [7]. Das Einschleusen kann hier entweder über URL Query Parameter, oder auch über den HTTP Host Header erfolgen, sofern dieser bei der Verarbeitung herangezogen wird. In den folgenden Beispielen wird allerdings lediglich der Weg über URL Query Parameter betrachtet. <?php $name = $_GET['name']; ?> <html><body> <form action="form.php" method="get"> <input type="text" name="name" value="<? echo $name ?>" />

Abbildung 5: Beispiel HTML Formular (serverseitig)

In diesem Beispiel wird über ein HTML Kontaktformular die Eingabe eines Wertes entgegengenommen. Nach Absenden der Anfrage über den Browser, wird dem Benutzer das Formular mit vorausgefüllten Werten erneut dargestellt.

Unter der Erwartung, dass eine herkömmliche, unschädliche Zeichenkette mit einem Namen eingegeben wurde (hier: Max Mustermann), würde dieser erneut dargestellt werden. <html><body> <form action="form.php" method="get"> <input type="text" name="name" value="Max Mustermann" />

Abbildung 6: Resultierendes HTML Formular (clientseitig)

Anstelle von harmlosen Angaben können für den Parameter name allerdings auch HTML Anweisungen integriert werden. Im vorliegenden Beispiel würde so eine Hinweismeldung im Browser mit der Zeichenfolge XSS erscheinen. <html><body> <form action="form.php" method="get"> <input type="text" name="name" value=""><script>alert('XSS')</script> <xss x="" />

Abbildung 7: Manipulieres HTML Formular (clientseitig)

Der einzig wirksame Schutz stellt hier die Überführung der HTML Anweisungen in unschädliche, darstellbare HTML Entitäten dar. In PHP wird dies durch die Verwendung der Funktion htmlspecialchars() erreicht. <?php $name=htmlspecialchars($_GET['name']); ?> <html><body> <form action="form.php" method="get"> <input type="text" name="name" value="<? echo $name ?>" />

Abbildung 8: XSS-sicheres HTML Formular (serverseitig)

<html><body> <form action="form.php" method="get"> <input type="text" name="name" value=""><script> alert('XSS') </script><xss x="" />

Abbildung 9: XSS-sicheres HTML Formulars (clientseitig)

Für die Verwendung von Benutzereingaben in JavaScript, ist die Kodierung in HTML Entitäten jedoch nicht ausreichend und möglicherweise sogar fehlerhaft. Für diesen Anwendungskontext existieren entsprechende Bibliotheken, um Steueranweisungen auszufiltern und zu entschärfen – beispielsweise durch die OWASP Enterprise Security API (ESAPI) [8].

3.3.3 Cross Site Request Forgery (CSRF) Bei diesem Szenario wird der Benutzer auf eine manipulierte Seite gelockt, um im Hintergrund eine HTTP Anfrage an eine externe Anwendung zu senden. Dabei wird angenommen, dass der Benutzer in dieser aufzurufenden Anwendung eine aktive Benutzer-Sitzung hat. So könnten beispielsweise Administratorenrechte ausgenutzt werden und neue Benutzer mit einem vorgegebenen Passwort angelegt werden. Für den Benutzer bleibt der Angriff im Normalfall verborgen [8].

Alternativ könnten seitenübergreifende Aufrufe auch per JavaScript und AJAX/XHR durchgeführt werden – jedoch werden diese von modernen Browsern mittels Same-Origin-Policy blockiert. Sendet die aufzurufende Seite allerdings einen entsprechenden HTTP Header, um diese Beschränkung zu umgehen, ist die Anwendung dennoch angreifbar [10]. Access-Control-Allow-Origin: *

Abbildung 10: HTTP Response Header, zur Deaktivierung der Same-Origin-Policy und somit Verwundbarkeit per CSRF

Beim Aufruf einer manipulierten Seite wird im nachfolgenden Beispiel die aktuelle Benutzer-Sitzung bei Wikipedia unbemerkt im Hintergrund beendet. <html> ... <link rel="stylesheet" type="text/css" href="https://de.wikipedia.org/w/index.php?title=Spezial:Abmelden" media="all"> ... <h1>Willkommen</h1>

Abbildung 11: Beispiel einer manipulierten Seite mit CSRF

Die Verwendung von Tokens bietet einen geeigneten Schutz gegen diese Art von Angriffen. Die zufällig erzeugten Werte sind einer Benutzer-Sitzung und einer bestimmten Aktion zugeordnet. Sie werden entweder an URL-Adressen angehängt oder als versteckte Felder in Formulare integriert. Bei der serverseitigen Verarbeitung wird zunächst die Korrektheit des Tokens geprüft, ist dieser nicht vorhanden oder ungültig, wird die Anfrage ignoriert und verworfen.

Es wird zwischen Session-Tokens (für die gesamte Dauer der Benutzer-Sitzung gültig) und One-Time-Tokens (für jeweils nur genau eine Aktion gültig) unterschieden. Letztere sind allerdings fehleranfällig, wenn der Benutzer über die Verlaufsfunktion (history.back) des Browsers zur vorherigen Seite zurückspringt und somit einen veralteten Token wiederverwendet.

3.3.4 Cross Site Tracing (XST) Ebenfalls wie bei Cross Site Request Forgery wird ein Benutzer auf eine manipulierte Internet-Seite gelockt. Allerdings ist hier nicht das Ziel, eine Aktion auf einer externen Seite direkt auszuführen, sondern vielmehr den gesendeten HTTP Header zu dieser externen Anwendung zu analysieren, um daraus den Session-Cookie einer aktiven Benutzer-Sitzung zu ermitteln. Dieses Angriffsszenario nutzt die HTTP TRACE Methode, welche somit auch vom Web-Server der entfernten Internet-Präsenz unterstützt und erlaubt sein müsste. Die Antwort auf eine Trace-Anfrage beinhaltet jene HTTP Header, die auch ursprünglich bei der Anfrage an die entfernte Anwendung gesendet wurden [11].

Innerhalb einer manipulierten Seite, wird dies meist im Intergrund über einen AJAX/XHR Aufruf bewerkstelligt. HTTP/1.1 200 OK Transfer-Encoding: Identity Content-Type: message/http Connection: close Server: Apache/2.4.6 (Linux/SUSE) Date: Tue, 03 Feb 2015 19:10:12 GMT TRACE /cgi/pg_Notenblatt/index.pl HTTP/1.1 Host: www1.primuss.de Cache-Control: max-age=0 Connection: keep-alive Origin:https://www1.primuss.de Cookie: ... User-Agent: Mozilla/5.0 (Macintosh; ...)

Abbildung 12: Beispiel einer HTTP TRACE Antwort

Da das einzige Angriffsziel die HTTP TRACE Methode ist, stellt deren Deaktivierung am Web-Server die wirkungsvollste Gegenmaßnahme dar. Zusätzlich dazu erkennen und verweigern auch hier moderne Browser, im Rahmen der Same-Origin-Policy, den Zugriff auf die entfernte Anwendung.

3.3.5 Session Hijacking Dieses Szenario tritt im Kombination mit Cross Site Scripting auf. Ein Angreifer ermittelt über eingeschleustes JavaScript den aktuellen Session-Cookie über das Objekt document.cookie und ist so in der Lage, durch eine separat selbst erzeugte HTTP Anfrage, diesen Cookie Header zu setzen und damit die Benutzer-Sitzung zu übernehmen.

Neben der prinzipiellen Vermeidung der Cross Site Scripting Möglichkeit, ist die Verwendung des httponly Attributs beim Setzen von Session-Cookies notwendig. So kann der Wert des Cookies nur vom Browser per HTTP übertragen werden, aber nicht mehr durch JavaScript ausgelesen werden. Zusätzlich existiert das Attribut secure, welches erzwingt, dass der Wert nur über eine sichere HTTPS Verbindung übertragen wird [12]. Set-Cookie: cookie_name=session_hash; path=/; secure; httponly

Abbildung 13: Beispiel eines sicheren Cookies in der HTTP Antwort, der nur per HTTPS übertragen werden kann

3.3.6 Session Fixation Bei diesem Angriff wird mittels Cross Site Scripting vom Angreifer der Wert für einen zukünftig zu erzeugenden Session-Cookie vorgegeben. Eine Unzulänglichkeit der Web Applikation führt dazu, dass beim Login des berechtigten Benutzers dieser

vorgegebene Wert auch für eine neue Benutzer-Sitzung wieder verwendet wird und so vom Angreifer übernommen werden kann. Das Auslesen des Cookies per JavaScript ist hier nicht notwendig. Die Gegenmaßnahme seitens der Anwendung besteht darin, beim Erzeugen einer serverseitigen neuen Benutzer-Sitzung ebenfalls einen zufällig gewählten neuen Session-Cookie auszustellen.

3.3.7 Information Disclosure Durch das Offenlegen von Informationen zu Versionsständen oder dem Aufbau einer Anwendung, erhalten Angreifer weiterführende Details, welche gezielte Angriffe begünstigen könnten [13]. Ebenfalls erlauben unterschiedliche Rückmeldungen auf unterschiedliche Eingabeparameter einer Applikation Rückschlüsse. Diese Anhaltspunkte können auch weniger offensichtlich im HTTP Header der Server-Antwort vorliegen.

Bei einem Login-Formular, zur Anmeldung mittels Benutzername und Passwort, sollte daher auf eine offenlegende Fehlermeldung wie „Benutzer nicht gefunden“ oder „Passwort nicht korrekt“ verzichtet werden und stattdessen lediglich „Login fehlgeschlagen“ zurückgegeben werden.

Bei technischen Fehlermeldungen und Abbrüchen (Exceptions) ist darauf zu achten, dass keine Informationen hinsichtlich Speicherpfaden oder beteiligter Komponenten des Produktiv-Systems ausgegeben werden.

3.3.8 Object Deserialization Werden dynamische Konfigurationseinstellungen über eine URL per HTTP an eine weitere Komponente übermittelt, können strukturelle Informationen durch Serialisierung und Deserialisierung beibehalten werden. Ein Sicherheitsrisiko entsteht allerdings, wenn anstatt flacher Daten (z.B. Arrays), komplexe Objekte übergeben werden, deren Destruktor Aktivitäten in Abhängigkeit zu Klassenvariablen durchführt [14][15].

Im folgenden Beispiel soll dynamisch ein Vorschaubild, für ein im Original größeres Bild, in einer Web Anwendung ausgegeben werden – die Ausgabegröße der Vorschau kann dabei variabel definiert werden. Die Parameter werden über ein Array übergeben, welches eine eindeutige Identifikation des Bildes, sowie die zu erzeugende Breite und Höhe enthält. http://.../thumbnail.php?params=a:3:{s:2:"id";s:2:"13";s:5:"width";i:64;s:6:"height";i:64;}

Abbildung 14: Beispiel-URL zur dynamischen Erzeugung eines Vorschaubildes in der Dimension 64 x 64 Pixel

Es wird nun weiter angenommen, dass in der gleichen Anwendung eine Klasse implementiert ist, die automatisch und aus guten Grund eine Ressource im Dateisystem anlegt, welche durch den Destruktor am Ende der Laufzeit wieder bereinigt und gelöscht wird. <?php class LockObject { protected $lockFile; public function __destruct() { unlink($this->lockFile); }

Abbildung 15: Implementierung einer Klasse mit Destruktor

Wird die vorher genannte Generierung der Vorschau mit manipulierten Parametern aufgerufen, die dieses Objekt in

serialisierter Form beinhalten, führt dies am Ende der Laufzeit ebenfalls zum Löschen der angegeben Ressource – im Beispiel beträfe dies eine Konfigurationsdatei, deren Fehlen die Web Anwendung unbrauchbar machen würde. Auf korrekte Kodierung der URL-Werte wurde hier zugunsten der Lesbarkeit verzichtet. http://.../thumbnail.php?params=a:1:{s:4:"evil";O:10:"LockObject":1:{s:11:"lockFile";s:20:"../configuration.php";}}

Abbildung 16: Manipulierte URL mit eingeschleustem Objekt

Da ursprünglich die Web Applikation die URL zum Vorschaubild erzeugt, ist es notwendig, dass die Parameter auch entsprechend signiert werden. Dies geschieht beispielsweise durch eine kryptographische Hashfunktion, unter Einbeziehung eines nur serverseitig bekannten Schlüssels. Dieser erzeugte Hash-Wert wird an die URL als zusätzlicher Parameter angehängt. Bei der Verarbeitung der Vorschau kann somit die Korrektheit, über den Vergleich von übermitteltem und erwartetem Hash-Wert, abgeleitet werden.

3.3.9 Denial of Service Im Gegenzug zu einem massenhaften Angriff auf die Infrastruktur mit dem Ziel deren Dienste zu überlasten, gibt es auch die Möglichkeit mit deutlich weniger Anfragen eine Anwendung zu überlasten. Dies ist beispielsweise möglich, wenn von außerhalb rechenintensive Prozesse einer Applikation direkt angestoßen werden können oder so auch Cache-Mechanismen temporär deaktiviert werden können.

Im Resultat erfolgt ebenso eine Überlastung der Systemressourcen – so können Speicherverbrauch, Lese-/Schreiboperationen oder auch die Prozessorlast künstlich erhöht werden. Reguläre Anfragen von herkömmlichen Benutzern könnten dann nicht mehr in der üblichen Zeit verarbeitet werden [16]. Eine wirksame Gegenmaßnahme beginnt bereits bei der Konzeption der Anwendung. Komponenten, die viele Ressourcen binden sollten nicht direkt über HTTP aufrufbar sein, sondern über eine zeitlich geplante Aktivität (Cron Job) ausgeführt werden.

4. WEITERE HILFSMITTEL Neben den Maßnahmen während der Konzeptions- und Entwicklungsphase von Anwendungen, gibt es noch einige zusätzliche Hilfsmittel, die mögliche Schwachstellen und Angriffsversuche ermitteln und reduzieren können. Ein kompletter Ausschluss von Angriffen ist allerdings nicht möglich.

4.1 Apache HTTP Server Module Im folgenden werden Module umrissen, welche von Drittanbietern für den Apache HTTP Server entwickelt und kostenfrei bereitgestellt werden.

4.1.1 mod_security Über vordefinierte Regeln werden ungültige HTTP Anfragen identifiziert und vom Web Server abgelehnt. Das Open Web Application Security Project stellt kostenlos ein Regelwerk [17] (Core Rule Set) zur Verfügung, welches beispielsweise Angriffsversuche hinsichtlich SQL Injection oder Cross Site Scripting erkennen und blockieren kann.

4.1.2 mod_evasive Dieses Modul [18] protokolliert die Zugriffe auf Ressourcen über HTTP. Falls eine bestimmte Ressource innerhalb eines definierten Zeitraums übermäßig viele Anfragen erhält, wird der Zugriff

blockiert. Diese Verhaltensweise ist ähnlich zu Intrusion Detection Systemen und bietet einen guten Basisschutz gegen DoS-, DDoS- und Brute-Force-Angriffe.

4.2 Analyseprogramme Die nachstehenden Projekte liefern weitere Anhaltspunkte für sicherheitsrelevante Schwachstellen einer zu prüfenden Anwendung. Allerdings ist auch hier die Vollständigkeit hinsichtlich der Sicherheitslücken nicht garantiert – das Ergebnis dieser Analysen ist somit lediglich als Grundlage zu verstehen.

4.2.1 Definierte Verfahren Das OpenVAS Projekt bietet eine virtuelle Maschine [19] an, samt einer Datenbank von bisher aufgedeckten Sicherheitslücken bei Infrastruktur-, System- oder Applikations-Komponenten. OpenVAS ist somit lediglich in der Lage, bereits bekannte Schwachstellen im zu prüfenden System zu erkennen.

4.2.2 Heuristische Verfahren Die Projekte Netsparker [20], Google Skipfish [21] und w3af [22] setzen heuristische Verfahren zum Aufdecken von Schwachstellen ein. So wird der Inhalt einer HTML-Seite analysiert und Parameterwerte mit unschädlichen, aber aussagekräftigen Bestandteilen aus den Bereichen SQL Injection und Cross Site Scripting manipuliert. Die weitere Betrachtung der Rückgabewerte nach der Verarbeitung durch eine Anwendung liefert Anhaltspunkte für mögliche Sicherheitslücken.

5. FAZIT Die Möglichkeiten, die sich einem Angreifer durch erfolgreiche Manipulationen erschließen sind vielversprechend, ausreichend motivierend und leider auch an der Tagesordnung. Sich im privaten wie gewerblichen Umfeld gegenüber Sicherheitsrisiken zu versperren ist somit wenig erfolgsversprechend. Vor allem als Architekt und Entwickler von Web Anwendungen ist es daher unbedingt notwendig, ein Sicherheitsbewusstsein zu entwickeln, sich über aktuelle Bedrohungslagen und Angriffsszenarien zu informieren, sowie den Zugriff auf Informationen kritisch zu hinterfragen. Gerade im Hinblick auf den Einsatz von sich täglich ändernden Frameworks, bedarf es einer Strategie, Sicherheitsaspekte ausreichend bewerten zu können – und im Bedarfsfall gezielt notwendige Gegenmaßnahmen zu ergreifen.

6. REFERENZEN & QUELLEN [1] Dokument „OWASP Top 10 - 2013“. In: OWASP – The

Web Application Security Project. Veröffentlichung: 31. August 2013, 13:38 UTC. URL: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf (Abgerufen: 3. Februar 2015, 13:21 UTC)

[2] Seite „confidentiality, integrity, and availability (CIA triad)“, In: TechTarget – Security management glossary. Bearbeitungsstand: November 2014. URL: http://whatis.techtarget.com/definition/Confidentiality-integrity-and-availability-CIA (Abgerufen: 3. Februar 2015, 13:22 UTC)

[3] Seite „BSI: G 2.157 Mangelhafte Auswahl oder Konzeption von Webanwendungen“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g02/g02157.html (Abgerufen: 3. Februar 2015, 14:17 UTC)

[4] Seite „BSI: G 2.158 Mängel bei der Entwicklung und der Erweiterung von Webanwendungen“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g02/g02158.html (Abgerufen: 3. Februar 2015, 14:18 UTC)

[5] Seite „SQL-Injection“. In: Wikipedia – Die freie Enzeklopedie. Bearbeitungsstand: 31. Januar 2015, 13:43 UTC. URL: http://de.wikipedia.org/wiki/SQL-Injection#Blinde_SQL-Injection (Abgerufen: 3. Februar 2015, 14:11 UTC)

[6] Seite „SQL Injection Prevention Cheat Sheet“. In: OWASP – The Web Application Security Project. Veröffentlichung: 7. Juni 2014, 7:53 UTC. URL: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet (Abgerufen: 3. Februar 2015, 14:21 UTC)

[7] Seite „BSI: G 5.170 Cross-Site Scripting (XSS)“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g05/g05170.html (Abgerufen: 3. Februar 2015, 14:23 UTC)

[8] Seite „Category: OWASP Enterprise Security API - OWASP“. In: OWASP – The Web Application Security Project. Bearbeitungsstand: 14. August 2014, 21:25 UTC. URL:https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API (Abgerufen: 6. Februar 2015, 18:13 UTC)

[9] Seite „BSI: G 5.171 Cross-Site Request Forgery (CSRF, XSRF, Session Riding)“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g05/g05171.html (Abgerufen: 3. Februar 2015, 14:23 UTC)

[10] Seite „Cross-Site Request Forgery (CSRF)“. In: OWASP – The Web Application Security Project. Bearbeitungsstand: 13. Dezember 2014, 12:31 UTC. URL: https://www.owasp.org/index.php/CSRF (Abgerufen: 4. Februar 2015, 17:44 UTC)

[11] Seite „Cross Site Tracing“. In: OWASP – The Web Application Security Project. Bearbeitungsstand: 10. November 2014, 14:53 UTC. URL: https://www.owasp.org/index.php/XST (Abgerufen: 4. Februar 2015, 17:49 UTC)

[12] Seite „BSI: M 4.394 Session-Management bei Webanwendungen“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL:

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04394.html (Abgerufen: 4. Februar 2015, 17:53 UTC)

[13] Seite „BSI: G 4.87 Offenlegung vertraulicher Informationen bei Webanwendungen“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g04/g04087.html (Abgerufen: 4. Februar 2015, 17:54 UTC)

[14] Seite „PHP Object Injection“. In: OWASP – The Web Application Security Project. Bearbeitungsstand: 7. Januar 2015, 12:50 UTC. URL: https://www.owasp.org/index.php/PHP_Object_Injection (Abgerufen: 4. Februar 2015, 17:59 UTC)

[15] Seite „CWE-502: Deserialization of Untrusted Data“. In: CWE - Common Weakness Enumeration. Bearbeitungsstand: 30. Juli 2014. URL: http://cwe.mitre.org/data/definitions/502.html (Abgerufen: 4. Februar 2015, 18:00 UTC)

[16] Seite „BSI: M 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen“. In: Bundesamt für Sicherheit in der Informationstechnik – IT-Grundschutzkataloge, Bearbeitungsstand: 13. EL, 2013. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04405.html (Abgerufen: 4. Februar 2015, 17:59 UTC)

[17] Seite "Rules". In: ModSecurity - Open Source Web Application Firewall. URL: http://www.modsecurity.org/rules.html (Abgerufen: 4. Februar 2015, 18:12 UTC)

[18] Seite "mod_evasive". In: Zdziarski's Blog of Things. URL: http://www.zdziarski.com/blog/?page_id=442 (Abgerufen: 4. Februar 2015, 18:14 UTC)

[19] Seite "OpenVAS-7 DEMO Virtual Appliance". In. OpenVAS - Open Vulnerability Assessment System. Bearbeitungsstand: Version 2.4, 19. Januar 2015. URL: http://www.openvas.org/vm.html (Abgerufen: 4. Februar 2015, 18:22 UTC)

[20] Seite "Netsparker, False Positive Free Web Application Security Scanner". URL: https://www.netsparker.com/ (Abgerufen: 4. Februar 2015, 18:15 UTC)

[21] Seite "skipfish - web application security scanner". In. Google Code. Bearbeitungsstand: 4. Dezember 2012. URL: https://code.google.com/p/skipfish/ (Abgerufen: 4. Februar 2015, 18:16 UTC)

[22] Seite "w3af - Open Source Web Application Security Scanner". URL: http://w3af.org/ (Abgerufen: 4. Februar 2015, 18:18 UTC)