Die Zunahme unerlaubter Cyber-Aktivitäten und die Nutzung von Web-Technologien im Alltag erhöhen die Anfälligkeit von Webanwendungen für Angriffe. Essenzielle Sicherheitsmaßnahmen wie Validierung, Filtering, und Verstärkung der Authentifizierung sollten bereits in der frühen Entwicklungsphase implementiert werden, um die Sicherheit zu gewährleisten. Angreifer nutzen Schwachstellen wie SQL-Injection und Cross-Site-Scripting, weshalb ein fortlaufender Prozess der Sicherheitsbewertung und -optimierung erforderlich ist.

1. Web Application Security
Oliver Hader
Aktuelle Themen zur Sicherheit im Web
Studiengang Master Internet Web
Hochschule Hof
oliver.hader@typo3.org
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

2. 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. 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 < &lt;
XML/HTML & &amp;
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

4. 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="&quot;&gt;&lt;script&gt;
alert('XSS')
&lt;/script&gt;&lt;xss x=&quot;" />
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.

5. 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:"i
d";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

6. 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:"e
vil";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%2
010%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/ITGrun
dschutzKataloge/Inhalt/_content/g/g02/g02157.html
(Abgerufen: 3. Februar 2015, 14:17 UTC)

7. [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/ITGrun
dschutzKataloge/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/ITGrun
dschutzKataloge/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/ITGrun
dschutzKataloge/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/ITGrun
dschutzKataloge/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/ITGrun
dschutzKataloge/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/ITGrun
dschutzKataloge/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)