Bei der Realisierung von Webanwendungen sollte das Thema Sicherheit bereits in der Entwicklungsphase ins Auge gefasst werden. Dies gilt auch beim Einsatz von vorgefertigten Webanwendungen wie Blogs, Foren oder Shopsystemen. Sich darauf zu verlassen, dass der beim Provider vorkonfigurierte Server bereits sämtliche Sicherheitslücken schließt, könnte sich als ein fataler Irrtum herausstellen. Um Ihnen einen Überblick über die populärsten Angriffsmöglichkeiten und deren Prävention zu geben, gehe ich detailliert auf das Cross-Site Scripting (XSS) und die SQL-Injection ein.

Bevor ich Sie mit diesen beiden Angriffsmöglichkeiten vertraut mache, erhalten Sie noch eine kompakte Übersicht weiterer Schwachstellen und Angriffsmöglichkeiten. Unter anderem sind die folgenden Sicherheitsrisiken aufzuführen:

• Denial of Service
• E-Mail-Injection
• Pufferüberlauf
• Session-Hijacking
• HTTP Response Splitting
• Remote Command Execution
• Man-In-The-Middle-Angriff
• Cross-Site Request Forgery (CSRF oder XSRF)

Mit einem Denial-of-Service-Angriff (DoS) versucht der Angreifer durch eine Vielzahl von Verbindungsanfragen dem
Webserver die Ressourcen
für reguläre Anfragen zu entziehen. Wird der Angriff von
mehreren Rechnern gleichzeitig durchgeführt, spricht man auch von einem
Distributed-Denial-of-Service -Angriff (DDoS). Ein DoS ist nicht auf
Webanwendungen beschränkt, sondern kann sich gegen jede Art von Server
richten.

Beim Man-In-The-Middle-Angriff (MitM) verbindet sich der Nutzer statt mit dem Webserver unbemerkt mit dem Rechner des Angreifers. Dieser „in the middle“-Rechner
startet bei jeder Anfrage des Nutzers seinerseits eine Anfrage an den
echten Webserver und gibt dessen Antwort an den Nutzer weiter.

Der
Nutzwert besteht für den Angreifer darin, Anfragen an oder Rückgaben
der Webanwendung beliebig manipulieren zu können. Gegen diese Art von
Angriff bietet nur die SSL-Verschlüsselung der Datenübertragung Schutz – dieser wird allerdings unwirksam, wenn sich der Angreifer
ein SSL-Zertifikat der betroffenen Website verschaffen kann, zu dem
ein Root-Zertifikat im Browser des Opfers installiert ist.

Bei einer E-Mail-Injection fügt der Angreifer
manipulierte Daten in ein Formular ein, so dass anstelle des beabsichtigten Empfängers
nun beliebige E-Mails an beliebige Empfänger gesendet werden. Diese Methode wird häufig für den Versand von SPAM missbraucht.

Bei einem Pufferüberlauf werden durch Fehler im Programm zu große
Datenmengen in einen dafür zu kleinen Speicherbereich geschrieben,
bis der Speicher überfüllt ist. Die überschüssigen Datenmengen überschreiben nun dem Ziel-Speicherbereich nachfolgende Informationen im Speicher. Der Angriff besteht darin, die überschreibenden
Daten so zu wählen, dass sie vom Programm als Befehle in
Maschinensprache interpretiert werden können.

Da HTTP ein verbindungsloses Protokoll ist, muss die Webanwendung die Identifikation eines Nutzers feststellen. Dies geschieht
anhand einer Session-ID, die jedem Request als Basic/Digest Authentication, Cookie,
URL-Rewriting oder HTTP-Form-Parameter (GET oder POST)
mitgegeben wird.

Beim Session-Hijacking versucht der Angreifer, Kenntnis
von der Session-ID des Nutzers zu erlangen, um dann mit dessen Identität und den dazugehörenden Rechten auf die Webanwendung
zuzugreifen.

Cross-Site Request Forgery setzt eine bestehende Session zwischen dem
Benutzer und der Webanwendung voraus. Der Angreifer
versucht dabei über verschiedene Techniken wie beispielsweise Cross-Site-Scripting
(XSS) den Nutzer oder über ein clientseitiges Skript auch direkt den
Browser zum Aufruf einer manipulierten URL zu bewegen. Anders als beim
Session-Hijacking erlangt der Angreifer selbst keine Kenntnis von
der Session-ID, da der Angriff ausschließlich im Browser des Nutzers
stattfindet.

HTTP Response Splitting ermöglicht es, Websites mit Hilfe von
gefälschten Anfragen zu verunstalten. Dabei wird nicht direkt auf den
Webserver Einfluss genommen, sondern es werden Systeme beeinflusst, die
dem Webserver vorgeschaltet sind. Solche vorgeschalteten Systeme
könnten beispielsweise ein Proxy-Server oder ein Cache-Server sein.
Darüber hinaus sind Cross-Site-Scripting oder Phishing-Angriffe über
HTTP Response Splitting möglich.

Beim Remote Command Execution versuchen Angreifer, Code auf einem
Server auszuführen. Dies geschieht in den meisten Fällen durch PHP
include()-Anweisungen. PHP erlaubt es, Dateien von
anderen Servern einzubinden – also auch vom Rechner eines
Angreifers. Darüber hinaus bietet PHP die Möglichkeit, lokale
Anwendungen über eine Shell aufzuführen. Werden diese mit
benutzermanipulierbaren Parametern aufgerufen und die Parameter nicht
entsprechend gefiltert, ist es möglich, weitere Programme aufzurufen.
So können etwa Dateien geändert oder sensible Daten ausgespäht werden.

Die wohl populärste Angriffsmöglichkeit stellt die SQL-Injection dar. Dabei sendet der Angreifer Verbindungsanfragen an den Webserver, wobei die Anfrage-Parameter mit SQL-Steuerzeichen versehen sind. Fängt die Webanwendung diese Steuerzeichen nicht ab, sondern sendet sie als Teil einer SQL-Abfrage an die Datenbank, kann der Angreifer entweder für ihn auf herkömmlichem Weg nicht zugängliche Daten auslesen oder Daten verändern. Zum Maskieren dieser SQL-Steuerzeichen bietet PHP die Funktionen „mysql_real_escape_string()“ oder „mysqli_real_escape_string()/real_escape_string()“.

Folgendes Fallbeispiel soll Ihnen einen Einblick verschaffen: Auf einem Webserver befindet sich das Skript shop.php zum Anzeigen von Artikeln. Das Skript akzeptiert den Parameter produktid, der innerhalb der Webanwendung ein Bestandteil der SQL-Abfrage wird.

Status	Erwarteter Aufruf
Aufruf	http://www.domain.de/shop.php?produktid=42
Code	SELECT * FROM produkte WHERE id=" . $_GET[‚produktid‘]
SQL-Abfrage	SELECT * FROM produkte WHERE id=42

Dieser Code übernimmt ungeprüft die URL-Variable produktid in eine SQL-Abfrage. Die ungefährlichste Angriffsmöglichkeit ist das Ändern dieser ID in der URL. Bei Datenbanksystemen, die Multi-Querys, also mehrere durch ein Semikolon „;“ getrennte SQL-Abfragen zulassen, kann dies zur Manipulation oder sogar zur Löschung von Daten führen.

Status	SQL-Injection
Aufruf	http://www.domain.de/shop.php?produktid=42;DELETE+FROM+proukte
Code	SELECT * FROM produkte WHERE id=" . $_GET[‚produktid‘]
SQL-Abfrage	SELECT * FROM produkte WHERE id=42;DELETE FROM produkte

Wie man unschwer erkennen kann, wird der Anwendung ein zweiter SQL-Befehl untergeschoben.

Um sich vor solchen SQL-Injection-Angriffen zu schützen, stellt Ihnen PHP eine Reihe nützlicher Funktionen und Verarbeitungsprozesse als Abwehrmöglichkeiten zur Verfügung. Die populärsten davon sind:

Die Verarbeitung von Sonderzeichen mit Hilfe der Funktionen „mysql_real_escape_string()“, „mysqli_real_esscape_string()“, „adds-lashes()“ oder „stripslashes()“ sollte in keiner Webanwendung fehlen. Vorteil bei diesen Funktionen: Man hat absolute Kontrolle über die eingefügten Backslashs und kann somit auf einfache Weise Sonderzeichen maskieren. Sie sollten jedoch vor dem Einsatz von „addslashes()“ mit Hilfe der Funktion „get_magic_quotes_gpc()“ überprüfen, ob die Option „magic_quotes_gpc“ an- oder ausgeschaltet ist. Falls die Option auf on steht, ist eine Behandlung mit „addslashes()“ nicht notwendig.

Die Filterung bestimmter Schlüsselwörter gehört ebenfalls zu den bekannten Abwehrmöglichkeiten. Vor allem die SQL-Schlüsselwörter SELECT, UNION, AND, OR und ORDER sollten gefiltert werden. Die Schlüsselwort-Filterung kann aber auch Probleme mit sich bringen, zum Beispiel wenn Feldinhalte wie „Union Investment“ oder „Europäische Union“ einschlägige Schlüsselwörter enthalten.

Seit MySQL 5 können die sogenannte hinterlegten Prozesse (engl. stored procedures) verwendet werden. Eine Stored Procedure ist eine Folge von SQL-Abfragen, die auf dem Server gespeichert bzw. hinterlegt werden können. Clients können auf diese Stored Procedure zugreifen, ohne sich um die Beschaffenheit der einzelnen Abfragen kümmern zu müssen. Datenbankanwendungen, die bei Banken und Versicherungen verwendet werden, nutzen häufig Stored Procedures, um ein sicheres Anwendungsumfeld zu schaffen. In einem solchen Umfeld hat ein Nutzer keine Möglichkeit, direkt auf eine Datenbanktabelle zuzugreifen. Er ist lediglich in der Lage, die gespeicherten Stored Procedures zu verwenden. Auf Stored Procedures können Nutzer unterschiedliche Nutzerrechte besitzen. Somit sind SQL-Injection-Angriffe nahezu ausgeschlossen.

Vorbereitete Abfragen (engl. prepared statements) oder gebundene Parameter (engl. Parameter Binding) erzeugen mit Hilfe eines sogenannten Query-Templates eine SQL-Abfrage, die auf dem MySQL-Server gespeichert wird. In PHP können Prepared Statements durch die neue MySQLi-Extension oder PHP Data Objects (PDO) verwendet werden.

Eine weitere äußerst populäre Angriffsmöglichkeit stellt das Cross-Site-Scripting (XSS) dar. Hinter dieser Bezeichnung verbergen sich zwei grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie beispielsweise JavaScript, in eine Webseite ein, die im Webbrowser des Opfers ausgeführt wird. Der Angriff nutzt dabei Sicherheitslücken bei der lokalen Ausführung der Skripte aus oder leitet eine Cross-Site Request Forgery ein. Unter serverseitigem XSS versteht man das Einschleusen von manipulierten Informationen in eine auf dem Webserver ausgeführte Skriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei ausführt.

Wie muss man sich einen solchen XSS-Angriff vorstellen? Auch hier bieten sich dem Angreifer mehrere Möglichkeiten. Besonders bequem ist es für potenzielle Angreifer, wenn die Daten des Angriffs permanent gespeichert werden, etwa in einem Blog, Gästebuch oder Forum. Dann nämlich wird der bösartige Code bei jedem Nutzer ausgeführt, der die Website besucht. Das Gefährliche daran ist, dass hier fremder Code im Kontext von eigentlich vertrauenswürdigen Webseiten ausgeführt wird.

Was kann man dagegen tun? Als Nutzer bzw. Besucher können Sie fast nichts tun, außer merkwürdige und vor allem recht lange Links nicht anzuklicken. Als Entwickler einer Webanwendung müssen Sie jedoch unbedingt Vorkehrungen gegen XSS treffen. Jede Ausgabe, die Nutzerdaten enthält, muss entwertet werden. Dabei gibt es spezielle Sonderzeichen, die je nach Kontext gefährlich werden können, wie beispielsweise <, >, ", ‚ und &. Diese Sonderzeichen müssen durch ihre HTML-Entitäten ersetzt werden, also &lt;, &gt;, &quot;, &apos; und &amp;. PHP bietet hierfür die Funktionen htmlspecialchars() und htmlentities() an.

Darüber hinaus sollten Sie auch aus Nutzereingaben HTML-Code entfernen – PHP liefert dafür mit der Funktion „strip_tags()“ genau das richtige Mittel.

Sollten Sie Maßnahmen gegen potentielle Gefahren und Schwachstellen ergreifen wollen, dürfte die folgende Tabelle eine brauchbare Checkliste darstellen:

Sicherheitslücke	Beschreibung
Verschlüsselung per SSL	Werden Autorisierungdaten unverschlüsselt und ohne SSL übertragen?
Passwort-Übertragung	Wird das Passwort per E-Mail unverschlüsselt übertragen?
Passwort-Qualität	Ist die Passwortwahl frei oder erzwingt die Anwendung sichere Passwörter (Länge, Zusammensetzung) über entsprechende Überprüfungen?
Standard-Zugänge	Legt die Anwendung über Installationsroutinen Standard-Zugänge, wie beispielsweise admin, root etc. an und vergibt hierbei Standardpasswörter?
Sensible Inhalte in Cookies	Werden Passwörter, Passwort-Hashes oder andere sensible Daten in Cookies gespeichert?
Remote-Code-Ausführung	Kann über einen Parameter PHP-Code von einem fremden Server ausgeführt werden, wie z. B. durch eine unsichere include()-Anweisung?
Session Fixation	Können Angreifer Session-IDs vorgeben, die dann von der Anwendung weiter verwendet werden?
Session Hijacking	Kann der Angreifer eine Session mit ihm bekannter Session-ID übernehmen? Gibt es Überprüfung auf User-Agent, IP etc.?
SQL-Injection (Formulare)	Kann ein Angreifer über ein Formular eigene SQL-Abfragen in die Anwendung einschleusen?
SQL-Injection (Cookies)	Werden IDs in Cookies gespeichert, anhand derer ein Angreifer SQL-Statements einfügen könnte?
SQL-Injection (URL-Parameter)	Können über URL-Parameter SQL-Abfragen eingeschleust werden?
XSS via XML	Können Angreifer über einen von der Anwendung verwendeten XML-Service, wie beispielsweise bei RSS-Feeds, Skriptcode einschleusen?
XSS (Formulare)	Kann an Eingabeformulare Skriptcode übergeben werden, der nicht gefiltert bzw. maskiert wird?
XSS (Cookies)	Werden Werte aus Cookies, wie beispielsweise Benutzer-IDs, ungeprüft übernommen?
XSS (User-Agent, Referrer)	Kann ein Angreifer über einen manipulierten User-Agent oder HTTP-Referrer Skriptcode einschleusen?

Eine weitere Gegenmaßnahme stellt der Einsatz von Web Application Firewalls (WAF) dar. Eine WAF ist eine Technologie, die Webanwendungen vor Angriffen über HTTP schützen soll. Gegenüber klassischen Firewalls und Intrusion Detection Systemen (IDS) untersucht eine WAF die Kommunikation auf der Dienstebene. Dazu ist normalerweise keine Änderung an den zu schützenden Webanwendungen nötig. Die WAF untersucht hierbei sämtliche eingehenden Anfragen und die Antworten des Webservers. Bei verdächtigen Inhalten wird der Zugriff unterbunden.

Zur Klassifizierung von gefährlichen oder verbotenen Aktionen wird häufig in einer vorgeschalteten Lernphase ein Application-Security-Scanner eingesetzt. Dieser analysiert, häufig im Dialog mit einem Nutzer, die Anwendung und erzeugt daraus Profile für zulässige Aktionen.

Alternativ werden durch eine Art Crawler oder auch Application-Security-Scanner die Webseiten der Webapplikation angesteuert und enthaltene Formularfelder überprüft. Die Applikation läuft in diesem Fall in einer Art passivem Modus, das heißt erlaubte und nicht erlaubte Eingaben werden in einer Logdatei festgehalten. Der Administrator kann dann nachträglich sehen, welche Aktionen im Betrieb geblockt würden und diese selektiv freischalten, indem er Sonderregeln einrichtet.

Zu den bekanntesten WAF-Vertretern gehören der USP Secure Entry Server und die ModSecurity für Apache-Webserver. Sie sollten sich jedoch im klaren darüber sein, dass auch eine WAF keine absolute Sicherheit gewährleistet.

Ein effizientes und optimiertes Sicherheitskonzept erfordert eine stetige Anpassung an neue Gegebenheiten und Sicherheitslücken. Während Sie die hier aufgeführten Schwachstellen schließen, erblicken sicher bereits neue Gefahrenquellen das Licht der Welt, welche Sie in die Planung und Realisierung eines Sicherheitskonzepts mit einbeziehen sollten.

Eines ist sicher: Eine absolut sichere Webanwendung gibt es nicht, aber durch eine vorausschauende Anwendungsentwicklung kann die Anpassung auf Gefahrenquellen deutlich erleichtert werden.