Diplomarbeit. - Sicherheit von PHP- und MySQL-basierten Webanwendungen -

Transkript

1 FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker (FH) Diplomarbeit - Sicherheit von PHP- und MySQL-basierten Webanwendungen - Betreuer: Dipl.-Inform. (FH) Jörg Muschiol Autor: Sebastian Schneider Ziegeleiweg Düsseldorf Matrikelnummer Düsseldorf, den 24. Juni 2009

2 I Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis VII VIII 1 Einleitung 1 2 Grundlagen PHP Funktionsweise Syntax Unterschiede zwischen PHP4 und PHP MySQL Funktionsweise Syntax Apache Webserver und das Betriebssystem Der Apache-Webserver Das Betriebssystem HTTP Funktionsweise Request-Methoden GET POST HTML und JavaScript HTML JavaScript Risiken Architekturbedingte Risiken von PHP Typendeklaration und Casting Typisierung Casting register_globals allow_url_fopen

3 II allow_url_include MySQL, Apache-Webserver und das Betriebssystem MySQL Apache-Webserver Betriebssystem SQL-Injections Grundlagen Verwundbarkeiten auffinden GET POST Cookies Servervariablen Syntax von MySQL-Injections WHERE Injection UNION SELECT Injection ORDER BY Injection INSERT-, UPDATE- und DELETE-Injections Gefahren durch SQL-Injections Diebstahl von Informationen Manipulation von Daten Authentifizierung umgehen DoS (Denial of Service) Übernahme der Anwendung / des Servers Header-Injections NULL-Byte-Injections Cross-Site Scripting Reflektive Angriffe Persistente Angriffe Lokale Angriffe XSS-Syntax Folgen von Cross-Site Scripting Logindaten ausspähen / Sessiondiebstahl Request Forgery Cross-Site Request Forgery Ablauf eines Cross-Site Request Forgeries Gefahren für das Intranet Datei-Uploads

4 III 4 Sicherungsmaßnahmen Das Betriebssystem PHP Installation Updates register_globals allow_url_fopen / allow_url_include Safe Mode Externe Sicherheitsmodule MySQL Apache-Webserver SQL-Injections Escaping Casting Blacklist-Filterung Prepared Statements Stored Procedures Header-Injections NULL-Byte-Injections Cross-Site Scripting erkennen und verhindern Kodierungen umwandeln und NULL-Bytes entfernen HTML entfernen HTML erlauben BBCode HTML-Filter Lokale Angriffe verhindern Cross-Site Request Forgery verhindern POST statt GET CAPTCHAS, Passwortabfrage und Bestätigungsmails Einsatz von Token Tag-Überprüfung Datei-Uploads absichern Sichere Softwarearchitektur Preisgabe von Informationen Informationen in der URL und in Formularen Kommentare, Metadaten und Dateialtlasten Login Authentifizierung SSL

5 IV Benutzernamen Passwortstärke Stammdatenprüfung Sichere Passwortverwaltung Salting Vergessene Passwörter Sessions Einstellungen Sessionnutzung zur Authentifizierung Automatisiertes Aufbereiten von Eingaben Funktionsweise Risiken Evaluation von drei Content-Management-Systemen Grundlagen Prüfschema Server Tests SQL-Injections Header-Injections NULL-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Typo Konfiguration Softwarekern SQL-Injections Header-Injections NULL-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Extensions SQL-Injections Header-Injections NULL-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Administrations-Backend SQL-Injections

6 V Cross-Site Request Forgery Sicherheitslücken in der Vergangenheit Ergebnis Joomla Konfiguration Softwarekern SQL-Injections Header-Injections NULL-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Extensions SQL-Injections Header-Injections Null-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Administrations-Backend SQL-Injections Cross-Site Request Forgery Sicherheitslücken in der Vergangenheit Ergebnis Drupal Konfiguration Softwarekern SQL-Injections Header-Injections Null-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Extensions SQL-Injections Header-Injections Null-Byte-Injections Cross-Site Scripting Cross-Site Request Forgery Administrations-Backend SQL-Injections Cross-Site Request Forgery

7 VI Sicherheitslücken in der Vergangenheit Ergebnis Vergleichsmatrix und Ergebnis Fazit 98 Literaturverzeichnis 99

8 VII Abkürzungsverzeichnis CODE Auszeichnung von Quellcode und Code-Segmenten BBCode Bulletin Board Code CMS Content-Management-System CSRF Cross-Site Request Forgery CSS Cascading Style Sheets DoS Denial of Service DDoS Distributed Denial of Service FTP File Transfer Protocol GNU GNU s Not Unix (rekursives Akronym) GPL General Public License HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol MD5 Message-Digest Algorithm 5 MIME Multipurpose Internet Mail Extensions PHP PHP: Hypertext Preprocessor (rekursives Akronym) SQL Structured Query Language SSL Secure Sockets Layer TCP Transmission Control Protocol TLS Transsport Layer Security URI Uniform Resource Identifier URL Uniform Resource Locator W3C World Wide Web Consortium WCMS Web-Content-Management-System WYSIWYG What You See Is What You Get XML Extensible Markup Language XSS Cross-Site Scripting

9 VIII Abbildungsverzeichnis 4.1 Token im Joomla-Quellcode Typo3-Kern SQL-Injection Testresultat Typo3-Kern Header-Injection Testresultat Typo3-Kern XSS Testergebnis Typo3-Kern Header-Injection Testresultat Typo3-Extension SQL-Injection Testresultat Typo3-Extension XSS Testresultat Typo3-Backend SQL-Injection Testresultat Typo3-Backend CSRF Testresultat Veränderte Webseite von Bundesinnenminister Dr. Wolfgang Schäuble Joomla-Kern SQL-Injection Testergebnis Joomla-Kern Header-Injection Testergebnis Joomla-Kern XSS Testergebnis Joomla-Kern CSRF Testergebnis Joomla-Extension SQL-Injection Testergebnis Joomla-Extension XSS Testergebnis Joomla-Backend SQL-Injection Testergebnis Joomla-Backend SQL-Injection Testergebnis Drupal-Kern SQL-Injection Testergebnis Drupal-Kern Header-Injection Testergebnis Drupal-Kern XSS Testergebnis Drupal-Kern CSRF Testergebnis Drupal-Extension SQL-Injection Testergebnis Drupal-Extension XSS Testergebnis Drupal-Backend CSRF Testergebnis Vergleichsmatrix Typo3, Joomla und Drupal

10 1 1 Einleitung Webanwendungen erfreuen sich seit einigen Jahren stetig wachsender Beliebtheit. Durch die immer weiter voranschreitende Technik konnten viele neue Funktionen entstehen. Mit PHP5 wurde ein großer Sprung in Sachen Objektorientierung und Performance vollzogen, sodass sich mit PHP auch sehr große Projekte verwirklichen lassen. In Kombination mit dem sehr populären MySQL-Server entstanden viele neue Webanwendungen. Doch durch die große Beliebtheit von PHP- und MySQL-basierten Webanwendungen entstanden auch vermehrt Sicherheitslücken, die von Angreifern ausgenutzt werden konnten. Einige Risiken, wie SQL-Injections, waren schon lange bekannt, traten aber vermehrt auf, da sich viele Programmierer der Gefahr nicht bewusst waren oder diese aus Flüchtigkeit übersahen. Andere Gefährdungen, wie Cross-Site Request Forgery, traten erst in der jüngeren Vergangenheit auf und sind noch nicht in das Bewusstsein vieler Programmierer vorgedrungen, so dass viele Projekte auf diese Risiken nicht adäquat abgesichert werden. Ziel dieser Ausarbeitung ist es, die Risiken und die dazugehörigen Sicherungsmaßnahmen ausführlich vorzustellen und zu beschreiben. Im Anschluss daran, sollen drei populäre Content-Management-Systeme auf Gefährdungen und die verwendeten Schutzmaßnahmen geprüft werden. Kapitel 2 bereitet die Grundlagen für das weitere Verständnis. Es werden PHP, MySQL, der Webserver, das Betriebssystem, http, HTML und JavaScript vorgestellt und erläutert. In Kapitel 3 werden ausführlich Risiken betrachtet, die auf die meisten PHP- Anwendungen zutreffen. Dazu gehören unter anderem die architekturbedingten Gefährdungen, die bei der Benutzung von PHP auftreten können. Die größte und am weitesten verbreitete Gefahr von SQL-Injections wird ausführlich erläutert. Es werden ebenfalls Risiken beleuchtet, die erst in der jüngeren Vergangenheit mehr zum Tragen gekommen sind. Dazu gehören unter anderem Cross-Site Scripting, welches JavaScript in die Anwendung einschleust, und Cross-Site Request Forgery, das im Namen eines Benutzers Anfragen ausführt, ohne dessen Wissen. Wie auf die in Kapitel 3 beschriebenen Gefahren reagiert werden kann, wird in Kapitel 4 ausgearbeitet. Dort werden verschiedene Techniken vorgestellt, mit deren Hilfe Webanwendungen gegen Risiken und Angriffe abgesichert werden kön-

11 2 nen. Dazu gehört die sichere Konfiguration von PHP, MySQL und dem Betriebssystem. Anschließend werden in Kapitel 5 drei populäre Content-Management- Systeme auf die beschriebenen Risiken und Sicherungsmaßnahmen getestet.

12 3 2 Grundlagen Webanwendungen nutzen PHP und MySQL als Grundlage sowie in vielen Fällen den Apache Webserver und Linux als Betriebssystem. HTML und JavaScript werden zur Anzeige der Webseiten im Browser des Benutzers benötigt. Per HTTP werden Anfragen des Benutzers an die Webanwendung und deren anschließende Antwort übertragen. Im Folgenden werden diese Grundlagen näher betrachtet, um das Verständnis der Funktionen und daraus resultierenden Risiken zu erhöhen. 2.1 PHP PHP 1 ist eine serverseitige Open Source Scriptsprache, die von der Syntax her an der Programmiersprache C angelegt ist 2. PHP wurde 1995 von dem Grönländer Programmierer Rasmus Lerdorf entwickelt 3. Lerdorf hatte PHP erst als Ersatz für eine Perl-Script-Sammlung verwendet, PHP stand zu diesem Zeitpunkt noch für Personal Home Page Tools. Lerdorf entwickelte jedoch bald eine erweiterte Version in C entschlossen sich Andi Gutmans und Zeev Suraski PHP von Grund auf neu zu schreiben, da sie der Ansicht waren, die bisherige PHP-Lösung würde neuen E-Commerce Anwendungen nicht genügen. Im Juni 1998 wurde schließlich PHP3 veröffentlicht. Zu diesem Zeitpunkt wurde auch der Name in PHP: Hypertext Preprocessor geändert 5. Die aktuelle Version ist PHP Funktionsweise PHP ist eine serverseitige Scriptsprache. Der PHP-Code wird auf dem jeweiligen Server von dem PHP-Interpreter verarbeitet. Die dabei generierte Ausgabe wird anschließend an die aufrufende Quelle, in den meisten Fällen ein Browser, geschickt. Bei dem größten Teil der von PHP generierten Ausgaben handelt es sich 1 rekursives Akronym für PHP: Hypertext Preprocessor 2 vgl. [PHP 2009] 3 vgl. [LERDORF] 4 vgl. [LERDORF 1995] 5 vgl. [PHP 2009(2)] 6 Stand

13 4 um reinen Text. PHP ist aber auch in der Lage, Binärdateien, wie Bilder oder PDF- Dateien zu generieren. Der Client braucht bis auf einen Browser kein spezielles Programm, um die generierten Daten darstellen zu können. Damit Webanwendungen überhaupt erst funktionieren können, benötigt PHP einen Webserver mit einer Schnittstelle zu dem PHP Interpreter. Das kann zum Beispiel der Apache Webserver sein, der gerade auf Linux-Systemen weit verbreitet ist, oder auch die Internet Information Services von Microsoft 7. PHP-Dateien haben in der Regel die Dateiendung.php, jedoch können je nach Konfiguration des Webservers beliebige andere Endungen genutzt werden Syntax Das Hallo Welt! -Programm hat sich in der Programmierung durchgesetzt, um auf möglichst einfache und schnelle Weise ein Programm mit der jeweiligen Programmiersprache zu erstellen, um einen kurzen Einblick in die Syntax der Sprache zu geben 8 : <?php echo Hallo Welt! ;?> Dieses kleine Code-Beispiel gibt die Zeichenkette Hallo Welt! im Browser des Benutzers aus Unterschiede zwischen PHP4 und PHP5 Viele Webhoster und Unternehmen setzen noch PHP4 auf ihren Servern ein, obwohl PHP5 schon im Juni 2005 veröffentlicht wurde und PHP4 seit August 2008 nicht mehr von der PHP Group supportet wird. Neben Bugfixes und kleineren Änderungen an Funktionen ist die größte Neuerung in PHP5 ein komplett neues Objektmodell. Unterstütze PHP4 die objektorientierte Programmierung nur ansatzweise, ist diese in PHP5 enorm verbessert worden. Dazu gehören Sprachkonstrukte, wie z.b. die Sichtbarkeit von Methoden und Variablen, Interfaces, Überladung und Autoloading 9. Neben dem neuen Objektmodell wurde auch der PHP-interne Zugriff auf MySQL verbessert 10 sowie 7 vgl. [MICROSOFT 2009] 8 vgl. [PHP 2009(18)] 9 vgl. [PHP 2009(3)] 10 vgl. [PHP 2009(4)]

14 5 ein XML-Parser eingeführt, mit dem PHP XML-Dateien vereinfacht verarbeiten kann MySQL Der MySQL Server ist ein freies, Relationales Datenbankverwaltungssystem unter der General Public License 12. Wem GPL nicht ausreicht, hat die Möglichkeit eine kommerzielle Lizenz zu erwerben. MySQL ist derzeit im Besitz von Sun Microsytems 13. MySQL wurde 1994 entwickelt und unterstützt in der aktuellen Version 5 weitgehend den SQL3-Standard Funktionsweise MySQL ist für zahlreiche Betriebssysteme erhältlich, neben Linux/Unix werden unter anderem auch Windows und das Apple OS X unterstützt. Anwendungen können mit dem MySQL-Server Verbindung aufnehmen und verschiedene Datenbankabfragen vornehmen Syntax Die Syntax von MySQL wird im Folgenden durch eine kurze SELECT-Abfrage veranschaulicht. SELECT ist eine der häufigsten verwendeten Abfragen und dient dazu, gespeicherte Daten aus der Datenbank abzurufen. SELECT Name FROM Kunden WHERE KundenNr = 12; Diese Abfrage ruft den Inhalt des Feldes Name aus der Tabelle Kunden ab, bei dem die Kundennummer 12 lautet. Bei der Abfrage handelt es sich um ein sehr einfaches Statement, die in Webanwendungen verwendeten Abfragen sind in den meisten Fällen weitaus komplexer. 2.3 Apache Webserver und das Betriebssystem Jede Webanwendung benötigt auf dem Server ein Betriebssystem und einen Webserver, der die Dokumente an den Browser des Benutzers ausliefert. 11 vgl. [PHP 2009(5)] 12 vgl. [GNU 2009] 13 vgl. [SUN 2009] 14 Structured Query Language; vgl. [SUN 2009(2)]

15 Der Apache-Webserver Der Apache HTTP-Server 15 von der Apache Software Foundation ist der meist genutzte Webserver im Internet 16. Der Apache Webserver ging aus dem NCSA httpd hervor und wurde 1995 als Version 1.0 veröffentlicht 17. Aktuell werden die Versionen , und frei zum Download angeboten Das Betriebssystem Der Apache Webserver lässt sich auf verschiedenen Betriebssystemen. Im Gegensatz zum Desktop-Bereich gehört Linux bei Servern zu den meist genutzten Betriebssystemen. Die Betriebssysteme unterscheiden sich hinsichtlich ihrer Konfiguration teilweise erheblich. 2.4 HTTP Das Hypertext Transfer Protocol ist ein Netzwerkprotokoll, das innerhalb von Netzwerken für die Datenübertragung verantwortlich ist. Es wird hauptsächlich zur Kommunikation zwischen Client und Server im World Wide Web genutzt, aber auch innerhalb von privaten Netzwerken. HTTP ist zustandslos, jede Anfrage wird als unabhängige Transaktion behandelt. HTTP wurde 1989 von Tim Berners-Lee bei der Europäischen Organisation für Kernforschung 19 entwickelt 20. HTTP benötigt ein Transportprotokoll, in den meisten Fällen wird dafür TCP verwendet Funktionsweise Soll eine Webseite von einem Server abgerufen werden, so stellt der Client (Browser) eine Anfrage an den jeweiligen Server, die angeforderte Datei zurückzusenden. 15 vgl. [APACHE 2009] 16 vgl. [NETCRAFT 2009] 17 vgl. [APACHE 2009(2)] 18 vgl. [APACHE 2009(3)] 19 CERN, vgl. [CERN 2009] 20 vgl. [BERNERS-LEE et al. 1996] 21 vgl. [USC 1981]

16 7 Die Anfrage könnte theoretisch so aussehen 22 : GET /index.php HTTP/1.1 Host: example.net Diese Anfrage fordert den Host example.net auf, die Datei index.php zurückzusenden. Die Antwort vom Server könnte folgendermaßen aussehen 23 : HTTP/ OK Server: Apache/ (Unix) PHP/5.2.8 Content-Length: 512 Content-Language: de Content-Type: text/html Connection: close It works! Der Server sendet den Inhalt der Datei index.php an den Client zurück. Der Statuscode 200 im Header bedeutet, dass die angeforderte Datei existiert. Der Inhalt der Datei lautet It works!. Der Browser des Clients gibt den Text anschließend aus Request-Methoden Es gibt verschiedene HTTP-Request-Methoden. Im Folgenden werden zwei dieser Methoden betrachtet, da sie für die Funktion von Webanwendungen besonders bedeutend sind GET Die GET-Methode ist wahrscheinlich die meist genutzte Form. Über die GET- Methode können auch Daten vom Client an den Server gesendet werden. Die zu sendenden Daten sind Teil der URL 24. Der zu sendende Teil wird mit dem? eingeleitet. Sollen mehrere Parameter übertragen werden, werden diese mit dem & voneinander getrennt. Enthalten die Werte Sonderzeichen, müssen die Daten 22 vgl. [BERNERS-LEE 1994] 23 vgl. [BERNERS-LEE 1994] 24 Uniform Resource Locator; vgl. [BERNERS-LEE 1994]

17 8 URL-kodiert 25 übertragen werden (z.b. würde ein & in den zu übertragenden Daten sonst einen weiteren Parameter einleiten). GET /index.php?page=start&id=2 HTTP/1.1 Host: example.net Wie im ersten Beispiel fordert der Client über diese Anfrage vom Server die Datei index.php an, übergibt in diesem Falle noch zwei Parameter page und id mit den Werten start und 2. Die GET-Methode besitzt keine Längenbeschränkung, diese wird aber oft von den verwendeten Browsern beschränkt. Auch können über GET keine Dateien an den Server gesendet werden POST Die POST-Methode ähnelt sehr der GET-Methode, jedoch werden hier die Daten nicht über die URL übertragen, sondern in einem separaten Datenblock. Dieser kann auch Dateien aufnehmen und an den Server senden, so können größere Datenmengen übertragen werden 26 : POST /index.php HTTP/1.1 Host: example.net Content-Type: application/x-www-form-urlencoded Content-Length: 48 page=start&id=2... Wie im GET-Beispiel wird die Datei index.php angefordert. Diesmal wurden die Daten nicht in der URL, sondern im Body-Bereich gesendet. Der Content-Type zeigt an, dass die Daten von einem Formular versendet wurden. 2.5 HTML und JavaScript HTML ist die Grundlage jeder Webseite. Ohne HTML könnten Webanwendungen im Browser des Benutzers nicht dargestellt werden. JavaScript wird seit einigen Jahren dazu genutzt um Webseiten auf der Clientseite dynamischer zu gestalten. Im Folgenden werden diese beiden Sprachen näher betrachtet. 25 vgl. [BERNERS-LEE 2005] 26 vgl. [BERNERS-LEE 1994]

18 HTML HTML 27 ist eine Auszeichnungssprache 28, um Texte, Bilder und andere Daten in Dokumenten zu strukturieren. HTML ist die Grundlage für Webseiten im World Wide Web. Browser interpretieren die Struktur der HTML-Dokumente und generieren daraus die grafische Anzeige. HTML und artverwandte Sprachen, wie z.b. XHTML und XML, werden vom World Wide Web Consortium, kurz W3C, entwickelt und verbessert 29. Der folgende Code zeigt eine simple Seite in HTML 4.01: <!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional //EN > <html> <head> <title>hallo Welt!</title> </head> <body> <h1>hallo Welt!</h1> </body> </html> 30 Dieses HTML-Dokument gibt im Browserfenster sowie im Browsertitel die Zeichenkette Hallo Welt! aus JavaScript JavaScript ist eine Scriptsprache, die häufig dazu genutzt wird statische HTML- Seiten auf der Clientseite dynamisch zu gestalten. Anders als der Name vermuten lässt, hat JavaScript kaum Gemeinsamkeiten mit der Programmiersprache Java. JavaScript wurde von Brendan Eich für den Netscape Navigator entwickelt und nannte sich damals noch Mocha. Aus Marketing-Gründen wurde die Sprache erst in LiveScript und anschließend in JavaScript umbenannt Hypertext Markup Language 28 Auszeichnungssprachen dienen zur Beschreibung von Daten unter Verwendung von Tags 29 vgl. [W3C 2009] 30 vgl. [W3C 1999] 31 vgl. [MOZILLA 2005]

19 10 JavaScript kann HTML-Dokumente durch das Document-Object-Model, kurz DOM 32, beliebig im Aussehen und in der Funktionalität ändern. JavaScript wird im Browser in einer Sandbox ausgeführt. Diese verhindert, dass JavaScript Zugriff auf das Dateisystem des Clients erlangt. Jedoch ermöglicht, je nach Sicherheitseinstellung, der Microsoft Internet Explorer erweiterten Zugriff, z.b. auf die Zwischenablage. Auch können Sicherheitslücken in Browsern genutzt werden, um Zugriff auf das Dateisystem zu erhalten. 32 vgl. [W3C 2005]

20 11 3 Risiken In diesem Kapitel werden verschiedene Sicherheitsrisiken vorgestellt, die in Webanwendungen auftreten können. 3.1 Architekturbedingte Risiken von PHP Es gibt die verbreitete Meinung, PHP sei eine unsichere Programmiersprache, da es zahlreiche Schwachstellen in der Konfiguration gäbe. Diese Schwachstellen treten allerdings nur in Verbindung mit schwach gesicherten Webanwendungen auf. Im Folgenden werden Konfigurationsoptionen vorgestellt, die bereits vorhandene Schwachstellen in Applikationen verstärken können Typendeklaration und Casting Typisierung dient bei Programmiersprachen dazu, dass die enthaltenen Variablen, Funktionen und Objekte ohne Fehler verwendet werden. Es kann zwischen starker und schwacher Typisierung, dynamischer und statischer Typisierung sowie expliziter und impliziter Typisierung unterschieden werden Typisierung PHP ist eine implizite, schwach typisierte, dynamische Programmiersprache. Das heißt, bei Variablen und Funktionen muss bei der Initialisierung der Typ nicht angegeben werden. Auch können Variablen ihren Typ zur Laufzeit ändern. Das folgende Beispiel veranschaulicht die Typisierung in PHP 1 : $x = 1; $y = 2 ; $z = $x + $y; // z hat jetzt den Wert 3 und den Typ int // ergibt das Gleiche $z = ; 1 vgl. [PHP 2009(10)]

21 12 In der ersten Zeile wird der Variablen $x explizit der Wert 1 zugewiesen, womit sie implizit vom Typ her Integer ist. Nun wird in der zweiten Zeile der Variablen $y die Zeichenkette 2 zugewiesen. Sie ist vom Typ String. Die Variable $z ergibt sich aus der Addition von $x und $y. Hier findet eine Typenkonvertierung statt, da PHP zur Laufzeit die Variable y von String nach Integer konvertiert. Das gleiche Beispiel würde bei der Programmiersprache Python einen Laufzeitfehler auslösen. Die automatische Typenkonvertierung von PHP kann für Fehler in der Anwendung verantwortlich sein. So können unerwartete Ergebnisse auftreten, wenn der Programmierer bei Vergleichen von Variablen nicht den Vergleichsoperator für Typensichere Vergleiche nutzt 2 : if(1 == "1"){ echo "true"; } else{ echo "false"; } //ergibt "true" if(1 === "1"){ echo "true"; } else{ echo "false"; } //ergibt "false" In diesem Beispiel wird zweimal geprüft, ob der Ausdruck wahr ist. Der erste if- Block ergibt true, da PHP die Zeichenkette 1 automatisch in den Typ Integer konvertiert. Im zweiten if-block wird der Operator für typsichere Vergleiche genutzt. Hier wird nicht nur der jeweilige Wert vergleichen, sondern auch der Typ. Der zweite if-block ergibt false, da zwar die verglichenen Werte übereinstimmen, jedoch nicht der Typ (Integer zu String). 2 vgl. [PHP 2009(6)]

22 13 Wird der typsichere Vergleich nicht genutzt, kann dies unter Umständen sogar zu SQL-Injections führen. Das Thema Injections wird ausführlich in den Kapiteln 3.3 und 4.5 behandelt Casting Will sich der Programmierer nicht auf die Konvertierung von PHP verlassen, kann er auch eine manuelle Typenkonvertierung vornehmen. $x = 1; $y = 2 ; $z = $x + (int)$y; Hier wird die Konvertierung zum Typ Integer erzwungen register_globals Ist in der Konfiguration von PHP die Option register_globals aktiviert, so stehen vom User übermittelte Variablen im globalen Bereich des jeweiligen PHP- Scripts zur Verfügung. Ist register_globals deaktiviert und übermittelt der Benutzer einen Wert per URL, kann im Script nur folgendermaßen auf den Parameter zugegriffen werden: //URL //Zugriff auf page $_GET[ page ] Hier kann nur über die Superglobale Variable 3 $_GET auf den vom Benutzer übermittelten Parameter zugegriffen werden. Anders sieht es aus, wenn die Option register_globals aktiviert ist: //URL //Zugriff auf page 3 Überall sichtbar

23 14 $page Der übermittelte Parameter steht jetzt als eigenständige Variable zur Verfügung. Auf den ersten Blick mag diese Option bequem erscheinen, doch entstehen Risiken, wenn die Architektur der Anwendung dies nicht berücksichtigt. Die Dokumentation von PHP verdeutlicht die Gefahren bei der Benutzung von register_globals: <?php if($username && $password) // kann vom User mit get/post/cookies übermittelt werden //user einloggen $good_login = 1; if($good_login == 1) // kann vom User mit get/post/cookies übermittelt werden fpassthru( /highly/sensitive/data/index.html );?> 4 Das Script erwartet eine Übergabe der Parameter username und password. Da register_globals aktiviert ist, können diese Parameter per GET, POST oder auch COOKIE übermittelt werden, auch wenn der Programmierer nur die Übergabe per COOKIE erwartet. Anschließend wird überprüft, ob es sich um einen validen Benutzer handelt (hier übersprungen). Ist dies der Fall, wird die vorher nicht initialisierte Variable $good_login auf 1 gesetzt. Der Anschließende if-block prüft diese Variable, und erteilt bei erfolgreichem Login Zugriff auf sensible Informationen. Der Programmierer hat jedoch nicht bedacht, dass der Benutzer nicht nur die Parameter username und password übermitteln kann, sondern ebenfalls den Parameter good_login. Wird dieser Parameter alleine mit dem Wert 1 an das Script übergeben, spielt es keine Rolle ob es sich um einen validen Benutzer handelt, da die Variable automatisch global zur Verfügung steht. Ein potenzieller Angreifer kann so an sensible Informationen gelangen, auch wenn er keine gültigen Logindaten vorweisen kann. Das Beispiel zeigt deutlich, dass nicht die Option register_globals eine Gefahr darstellt, sondern wie der Programmierer mit dieser Option umgeht. Im Kapitel 4.9 wird näher auf sichere Softwarearchitektur eingegangen und wie sich Gefährdungen vermeiden lassen, auch wenn regsiter_globals aktiviert 4 vgl. [PHP 2009(7)]

24 15 ist allow_url_fopen In PHP können Dateien zur Laufzeit von einem Script nachgeladen werden. Die meisten größeren Anwendungen machen davon Gebrauch, um Module und spezielle Funktionen dynamisch zu laden. Die Dateien befinden sich meistens lokal in einem Unterordner der jeweiligen Anwendung und werden z.b. mit include() oder require() geladen. Oft sollen auch Textdateien, z.b. für das Parsen von XML, eingelesen werden. Dafür steht in den aktuellen PHP-Versionen file_get_contents() zur Verfügung. Ist die Option allow_url_fopen in der Konfigurationsdatei php.ini aktiviert, ist ein Laden von entfernten Dateien (also Dateien, die sich auf einem anderen Server befinden) möglich. Die Funktionen sind so nicht mehr auf lokale Dateien beschränkt, sondern können auch Dateien per HTTP und FTP einlesen. Je nach Architektur der Anwendung ergeben sich hierdurch Gefährdungen, die den gesamten Server kompromittieren können allow_url_include Vor der Veröffentlichung von PHP 5.2 standen Serveradministratoren und Programmierer vor dem Problem, dass sie zwar Zugriff auf entfernte Dateien ermöglichen wollten, jedoch nur per include() und require() und nicht über andere Dateifunktionen, wie file_get_contents() oder fopen(). Da dies nicht möglich war, wurde die Option allow_url_fopen meist aktiviert. Diesem Problem wurde mit der PHP-Version 5.2 Rechnung getragen. In dieser Version wurde die Option allow_url_include eingeführt, die das Einlesen von entfernten Dateien nur per include(), include_once(), require() und require_once() erlaubt. Alle anderen Dateifunktionen können weiterhin nur auf lokale Dateien zugreifen. Sicherheitsrisiken durch eine fehlerhafte Architektur der Anwendung kann aber auch diese Option nicht ausgleichen, wenn die Gefährdung durch eine include()- oder require()-anweisung erfolgt.

25 MySQL, Apache-Webserver und das Betriebssystem Architekturbedingte Risiken können nicht nur in der Programmiersprache auftreten, sondern auch im Datenbankserver, dem Webserver und dem Betriebssystem MySQL Schwachstellen in MySQL sind zwar selten, aber wie bei jeder Software treten auch bei MySQL Bugs oder auf Windows Systemen Virenbefall auf. Je nach Konfiguration wird es Angreifern erleichtert in die Datenbank einzudringen, in dem er direkt eine Verbindung zu dem MySQL Server aufbaut. Oftmals wird der MySQL- Server ohne Passwort für den Benutzer root 5 installiert. Ist dies der Fall, kann ein Angreifer sich ohne Umweg über eine Webanwendung Zugriff auf den MySQL- Server verschaffen, wenn das Betriebssystem diese Zugriffe nicht unterbindet. Oftmals hat der Datenbankbenutzer, über den die Webanwendung sich bei dem Datenbankserver anmeldet, zu viele Rechte. So kann über eine SQL-Injection unter Umständen die Struktur der Datenbank geändert werden Apache-Webserver Der Apache-Webserver gilt allgemein als ein sehr sicherer Webserver. Er ist über lange Zeit erprobt und es erscheinen regelmäßig Updates. Jedoch ist auch der Apache-Webserver nicht von Fehlern in Modulen befreit. So traten Anfang 2008 unter anderem XSS-Schwachstellen in den Modulen mod_status, mod_proxy_ftp, mod_proxy_balancer und mod_autoindex auf 6. So ließ sich durch Manipulation von Parametern JavaScript-Code im Browser des Benutzers ausführen Betriebssystem Betriebssystemsicherheit kann ein komplettes Buch füllen. Der Vollständigkeit halber sollen hier nur erwähnt werden, dass Betriebssysteme, wie auch Webanwendungen, Risiken aufweisen können. Ein bekanntes Risiko ist das Auslesen von geschützten Dateien durch einen Angreifer. Im Laufe der nächsten Kapitel wird darauf näher eingegangen. 5 root: der Systemadminsitrator auf Linux-/UNIX-Systemen 6 vgl. [HEISE 2008] 7 weiterführende Literatur: [KERSKEN 2005]

26 SQL-Injections SQL-Injections sind Code-Einspeisungen, mit denen ein Angreifer versucht eigene SQL-Befehle von der Anwendung ausführen zu lassen. Sie gehören zu den häufigsten und gefährlichsten Angriffen auf Webanwendungen und Server. Gerade in den letzten Jahren hat die Anzahl an SQL-Injections stark zugenommen, da auch immer mehr datenbankbasierte Webanwendungen entwickelt wurden. Bei diesen dynamischen Anwendungen stammen Werte bei Datenbankabfragen meist aus Benutzereingaben. Diese Eingaben können aus GET, POST, COOKIE oder auch Headerwerten stammen. Ist die Webanwendung unzureichend gesichert und gibt ein Angreifer anstelle der erwarteten Werte ein eigenes Datenbankstatement ein, handelt es sich um eine SQL-Injection Grundlagen Um zu verstehen, wie Angreifer eigene Datenbankstatements in die Anwendung einschleusen und erfolgreich zur Ausführung bringen können, werden hier die Grundlagen dazu beschrieben. Datenbankfelder haben in der Regel verschiedene Typen 8 : String Number Date Blob Für Injections sind die Typen String, Number und Date wichtig. Blob stellt in MySQL ein binäres Feld dar, in dem komplette binäre Daten (z.b. Bilder) gespeichert werden können. Blob-Felder spielen bei Injections in der Regel keine Rolle. Wird an die Datenbank ein Wert vom Typ String oder Date übergeben, muss dieser Wert mit Hochkommata ( ) oder durch Anführungszeichen ( ) umschlossen sein. Werte vom Typ Number (int, float, double, etc.) können dagegen einfach im Statement verwendet werden. SELECT vorname FROM kunden WHERE name = Meier ; 8 vgl. [KUNZ ESSER 2008, S. 123]

27 18 Dieses Statement gibt alle Vornamen der Kunden aus, die den Nachnamen Meier tragen. Da Meier vom Typ String ist, muss er durch Hochkommata oder Anführungszeichen umschlossen werden. Wäre dies nicht der Fall, würde von der Datenbank ein Fehler zurückgegeben werden. SELECT vorname FROM kunden WHERE kndnr = 12; Dieses Statement gibt den Vornamen des Kunden mit der Kundennummer 12 aus. Hier muss die Kundennummer nicht umschlossen werden, da sie vom Typ Integer ist. Dem Datenbankstatement kann natürlich auch eine Variable übergeben werden. SELECT vorname FROM kunden WHERE kndnr = $_GET[ kndr ]; Diese Abfrage übernimmt ungeprüft den Wert der Variable kndr, die per GET vom Benutzer über die URL übergeben wurde Verwundbarkeiten auffinden Um einen erfolgreichen Angriff auf eine Webanwendung zu starten, muss der Angreifer zuerst testen, wo die Anwendung verwundbar ist. Dazu sucht er Parameter, die Benutzereingaben an die Datenbank weiterleiten. Dazu gehören Parameter aus GET POST COOKIE SERVER Angriffe können durch Manipulation von Werten dieser Parameter erfolgen GET GET-Parameter können vom Angreifer am leichtesten manipuliert werden, da diese über die URL übergeben werden 9. 9 siehe Kapitel

28 19 Hier erwartet die Anwendung die Übergabe einer Kundennummer. Um zu testen, ob eine Schwachstelle besteht, kann der Angreifer Hochkommata und Anführungszeichen an die URL anhängen: Übernimmt die Anwendung die vom User übergebenen Werte ohne Prüfung in ein SQL-Statement, tritt ein Fehler auf. Das dazugehörige PHP-Script könnte so aussehen: $kndr = $_GET[ kndr ]; $sql = SELECT vorname FROM kunden WHERE kndnr = $kndr ; $result = mysql_query($sql); Das Script nimmt den Parameter kndr entgegen und baut ihn in die SQL-Abfrage ein. Da der Wert nicht auf seine Gültigkeit geprüft wurde, kommt folgende Abfrage bei der Datenbank an: SELECT vorname FROM kunden WHERE kndnr = 12 ; Da es sich aufgrund der Fehlerhaften Zeichensetzung nicht um ein gültiges SQL- Statement handelt, gibt die Datenbank eine Fehlermeldung aus, die wie folgt aussehen könnte 10 : Warning: Supplied argument is not a valid MySQL result resource in index.php on line... Diese Fehlermeldung liefert dem Angreifer wichtige Informationen. Er weiß nun, um welche Datenbank es sich handelt, und dass die Benutzereingaben ungeprüft in das SQL-Statement übernommen werden POST Die Manipulation von POST-Parametern gestaltet sich etwas schwieriger. Diese Parameter werden mittels HTML-Formularen übergeben. Sind dort freie Eingabefelder enthalten (z.b. für Benutzernamen oder Passwörter), kann der Angreifer 10 vgl. [SUN 2009(3)]

29 20 dort verschiedene Zeichenfolgen eingeben. <input name="name" size="20" /> Lässt das Formular nur Listen oder vorselektierte Werte zu, gehen viele Webmaster davon aus, dass keine Manipulation stattfinden kann. <form action="index.php" method="post"> <select name="farbe"> <option value="1">rot</option> <option value="2">grün</option> <option value="3">blau</option> </select> </form> Hier hat der Benutzer nur die Wahl aus vorselektierten Werten. Eine Manipulation scheint auf den ersten Blick nicht möglich. Doch auch durch solche Listen lässt sich ein Angreifer kaum aufhalten. Er wird die HTML-Datei lokal auf seine Festplatte abspeichern und kann anschließend ohne Probleme die Werte anpassen: <form action=" method="post"> <select name="farbe"> <option value="1 \"">Rot</option> </select> </form> Der Angreifer ändert die relative URL in eine absolute und setzt in das value- Attribut Sonderzeichen ein. Durch lediglich zwei kleine Änderungen kann nun ein manipuliertes Formular an den Server gesendet werden Cookies Cookies werden in vielen Webanwendungen zur Identifikation von Benutzern nach Logins verwendet. Oft wird ein Hash oder eine ID in das Cookie geschrieben und auf den Folgeseiten mit der Datenbank abgeglichen. Durch Browser-Plugins, wie es sie z.b. für den Mozilla FireFox gibt 11, können gespeicherte Cookies sehr einfach verändert werden. Das Prinzip bleibt auch bei dieser Methode dasselbe. Der Angreife ändert den Cookie mit Sonderzeichen ab und hofft auf eine anschließende Reaktion der Anwendung. 11 vgl. [MOZILLA 2009]

30 Servervariablen PHP bieten dem Programmierer sehr einfach Zugriff auf die vom Browser gesendeten Header-Informationen. Die Header-Daten enthalten unter anderem Information über den benutzten Browser, das Betriebssystem, IP-Adresse, Host und Referer. Mittels $_SERVER erhält der Programmierer Zugriff auf diese Informationen. Viele Programmierer gehen sehr sorglos mit den Inhalten der Servervariablen um und vertrauen den Inhalten dieser Variablen. Doch mittels Add-Ons und anderer Software können ohne größere Probleme Headerinformationen verändert werden. Werden diese Daten ungeprüft in ein Datenbankstatement übernommen, ist die Anwendung dort genau so für Injections anfällig, wie bei GET oder POST Daten Syntax von MySQL-Injections Hat der Angreifer erfolgreich eine Schwachstelle gefunden, kann er versuchen eigene Datenbankbefehle einzugeben. Je simpler das vorhandene SQL-Statement ist, desto einfacher ist auch eine Injection. Handelt es sich dagegen um eine komplizierte Abfrage, werden oft sehr viele Versuche benötigt, bis die Injection zu einem Erfolg führt WHERE Injection Als Beispiel für eine einfache WHERE-Injection, kann das bereits gezeigte Beispiel dienen: //URL $kndr = $_GET["kndr"]; $sql = "SELECT vorname FROM kunden WHERE kndnr = $kndr"; $result = mysql_query($sql); //Statement SELECT vorname FROM kunden WHERE kndnr = 12; Die Anwendung erwartet hier eine Kundennummer, die per URL übergeben wird. Durch das Einspeisen von verschiedenen Sonderzeichen konnte der Angreifer bereits die Schwachstelle in Erfahrung bringen. Wird anstelle der Kundennummer

31 22 12 ein anderes Konstrukt eingegeben, kann sich ein Angreifer sämtliche Kunden ausgeben lassen 12 : //URL OR 1=1 //Statement SELECT vorname FROM kunden WHERE kndnr = 12 OR 1=1; Da das an die Kundennummer angehängte Statement OR 1=1 immer zutrifft, werden alle Einträge aus der Tabelle ausgegeben. Das Ändern von WHERE-Klauseln ist eine oft gebrauchte Injection, die in vielen Anwendungen zum Erfolg führt, wenn diese für Injections anfällig ist. Hierbei können Daten ausgelesen werden, die dem Angreifer auf normalem Wege nicht zugänglich sind UNION SELECT Injection Im SQL-Statement ist zwar die Tabelle der Datenbank angegeben und auf den ersten Blick scheint der Angreifer nur auf Daten dieser Tabelle zugreifen zu können. Doch über das MySQL-Schlüsselwort UNION können nach der WHERE-Klausel mehrere Tabellen miteinander verknüpft werden. Damit eine UNION-Abfrage erfolgreich ausgeführt werden kann, muss der Angreifer die Anzahl der Felder (und je nach Datenbank auch den Typ) im vorhandenen Statement kennen. Um an diese Anzahl zu gelangen, kann der Angreifer raten und verschiedene Statements testen. Handelt es sich um eine Open-Source Anwendung, kann er in der jeweiligen Datei das Originalstatement einfach auslesen. Sind alle Voraussetzungen geschaffen, ist ein Zugriff auf beliebige Tabellen der Datenbank möglich. Je nach Konfiguration gehören sogar Systemtabellen dazu, in denen Information zu den einzelnen Datenbankbenutzern gespeichert sind 13. SELECT vorname, name, hausnr FROM kunden WHERE kndnr = 12 UNION SELECT username, passwort, 1 FROM benutzer; Dieses Statement liest über die UNION-Klausel den Loginnamen und das Passwort des Benutzers aus. Da im ersten SELECT drei Spalten ausgelesen werden ( vorname, name und hausnr ) muss auch das UNION SELECT aus drei Spalten bestehen. Die Benutzertabelle besteht in diesem Beispiel aus drei Spalten, deswegen muss der Angreifer einen zusätzlichen Wert (hier die 1 ) in die UNION- Klausel einbringen. Da die Spalte hausnr offensichtlich vom Typ Integer ist, hat 12 vgl. [HEIDERICH et. al 2009, S. 529] 13 vgl. [KUNZ ESSER 2008, S. 133ff]

32 23 der Angreifer die 1 als Wert eingegeben. MySQL führt eine automatische Typenkonvertierung durch, aus dem Grund hätte der Angreifer anstelle der 1 auch einen String eingeben können (z.b. foo ). Andere Datenbanksysteme, wie MS- SQL, verlangen bei der UNION-Klausel aber den gleichen Datentyp ORDER BY Injection Um an geschützte Informationen einer Datenbank zu gelangen, benötigt ein Angreifer nicht unbedingt ein SELECT-Statement, je nach Architektur der Anwendung reicht eine ungesicherte ORDER BY Anweisung aus 14. SELECT name FROM benutzer ORDER BY $_GET[ order ]; Diese Abfrage gibt alle Namen aus der Tabelle benutzer aus. Sortiert wird die Liste durch eine Variable, die über GET vom Script ungeprüft entgegengenommen wird: Hier würde die Liste nach dem Vornamen sortiert werden. Wie bei der UNION SELECT Injection ist auf den ersten Blick die Verwundbarkeit nicht sofort zu erkennen, da Informationen durch unterschiedliches Sortieren nicht ausgelesen werden können. Durch eine andere Sortierung der Liste kann ein Angreifer unter Umständen auf die gespeicherten Informationen schließen. Sind jetzt, so wie in vielen Fällen, auch mit MD5 gehashte Passwörter in dieser Tabelle gespeichert, kann ein Angreifer nach und nach alle Buchstaben des Passwortes erraten: 15 SELECT name FROM benutzer ORDER BY (id = 1 && substring(password,1,1) = 0 ) DESC, id DESC; Dieses Statement sortiert die Liste nach der Benutzer-ID und dem ersten Zeichen des Passwort Hashs. Als id wird hier 1 genutzt, da der Administrator meist der erste Benutzer im System ist und somit die 1 erhält. Es kann aber auch jede andere ID verwendet werden. Im zweiten Teil der Anweisung wird nach dem ersten Zeichen des Passwort Hashs sortiert (hier eine 0 ). Ist die Abfrage erfolgreich, wird der Administrator in der ersten Zeile der Liste ausgegeben. MD5 16 erzeugt einen 32-Zeichen langen Hash, der aus den Ziffern 0-9 und den Buchstaben a bis f besteht. Pro Stelle können also 16 verschiedene Zeichen stehen, der Angreifer benötigt demnach maximal 480 Versuche, bis er ihn 14 vgl. [KUNZ ESSER 2008, S. 138] 15 vgl. [KUNZ ESSER 2008, S. 138] 16 Message-Digest Algorithm 5, vgl. [RIVEST 1992]

33 24 erfolgreich ausgelesen hat (15*32, da nach dem 15. fehlgeschlagenen Versuch das letzte Zeichen bekannt ist und nicht mehr getestet werden muss). Nach der Wahrscheinlichkeit wird der Angreifer keine 480 Versuche benötigen, da er viele Zeichen schon vor dem letzten Versuch finden wird. Durch zusätzliche SQL- Techniken kann diese Zahl noch weiter verringert werden. Nutzt der Angreifer ein automatisiertes Script, kann er den Hash innerhalb weniger Sekunden auslesen. Den Hash kann er anschließend mit Rainbow-Tables abgleichen oder auch in einem Cookie nutzen, falls die Anwendung den Hash als Identifikationsmerkmal für den Login nutzt. Damit der hier beschriebene Angriff erfolgreich durchgeführt werden kann, muss der Angreifer die Namen der Tabellenfelder kennen. Handelt es sich um Individualsoftware, ist die Wahrscheinlichkeit gering, dass ein Angreifer diese Namen kennt. In dem Falle kommt er möglicherweise durch Testen von verschiedenen Namen zum Ziel, da für Passwörter oftmals Namen wie password, passwd, etc. genutzt werden. Setzt die Anwendung Open-Source Software ein, lässt sich der Name einfach aus dem Quelltext ersehen INSERT-, UPDATE- und DELETE-Injections Nicht nur bei lesenden SQL-Abfragen droht die Gefahr einer Injection, sondern auch bei INSERT-, UPDATE- oder DELETE-Anweisungen. Werden von einem Angreifer dort Manipulationen vorgenommen, sind diese meist folgenschwer, da Datensätze verändert oder sogar gelöscht werden. Die Vorgehensweise unterscheidet sich dabei kaum von den bisher vorgestellten SQL-Injections. Bei einem UPDATE oder DELETE schleust der Angreifer in den WHERE-Teil der Abfrage eigenen Code ein. So kann er beliebige Datensätze bearbeiten oder löschen. Da bei INSERT-Anweisungen keine WHERE-Klauseln zum Einsatz kommen, sehen Injections hier etwas anders aus. INSERT INTO warenkorb VALUES (12, b-12345, Blau ); Diese Anweisung erstellt in der Tabelle warenkorb eines Online-Shops einen neuen Datensatz. Die Informationen werden ohne Prüfung in die Anweisung übernommen. Übermittelt nun ein Angreifer einen manipulierten Wert, kann er eine Injection zur Ausführung bringen 17 : INSERT INTO warenkorb VALUES (12, b-12345, (SELECT passwort FROM benutzer WHERE name = Admin )) --,, ); 17 vgl. [HEIDERICH et. al 2009, S. 534]

34 25 Anstelle der Anzahl der Waren, gibt der Angreifer die folgende Zeichenkette ein: 12, b-12345, (SELECT passwort FROM benutzer WHERE name = Admin ))-- Zwei Bindestriche am Ende der SQL-Anweisung leiten einen Kommentar ein, so dass die nachfolgenden Anweisungen ignoriert werden. Bei INSERT-Anweisungen können nicht nur Zeichenketten oder Zahlen verwendet werden, sondern auch komplette SELECT-Anweisungen, deren Ergebnis anschließend in den Datensatz übernommen wird. Diese Funktion macht sich der Angreifer hier zunutze, in dem er das Passwort das Administrators an die Stelle der Artikelfarbe setzt. Betrachtet der Angreifer anschließend seinen Warenkorb, wird er dort das Administratorpasswort vorfinden. Da der Angreifer die Struktur der Tabelle kennt, behält er auch die Spaltenanzahl bei, da ansonsten ein Fehler ausgegeben würde. Je nach Konfiguration können UPDATE-Anweisungen auch nach einer WHERE- Anweisung stehen, wenn sie durch ein Semikolon getrennt werden Gefahren durch SQL-Injections In diesem Kapitel werden nun die aus SQL-Injections resultierenden Risiken und Folgen näher betrachtet. Dazu gehören: 1. Diebstahl von Informationen Manipulation von Daten Umgehen einer Authentifizierung DoS (Denial of Service) Übernahme der Anwendung / des Servers Diebstahl von Informationen Sollen Informationen nur einem geschlossenen Kreis (oder auch niemanden) zugänglich gemacht werden, können SQL-Injections von einem Angreifer dazu genutzt werden, um an diese Informationen zu gelangen. Wie die UNION SELECT Injection gezeigt hat, benötigt der Angreifer für den Informationsdiebstahl nur eine 18 vgl. [HEIDERICH et. al 2009, S. 530] 19 vgl. [HEIDERICH et. al 2009, S. 533] 20 vgl. [HEIDERICH et. al 2009, S. 529] 21 vgl. [HEIDERICH et. al 2009, S. 532] 22 vgl. [HEIDERICH et. al 2009, S. 535]

35 26 verwundbare Stelle in der Anwendung. Durch diese kann er aus der vorhandenen Tabelle ausbrechen und Daten aus beliebigen anderen Tabellen auslesen. Doch nicht nur Inhalte der Datenbank können von einem Angreifer ausgelesen werden. Oftmals liegen.htpasswd 23 - oder andere sensible Dateien in höher gelegenen Verzeichnissen, die von außen nicht zugänglich sind. Um an den Inhalt der Dateien zu gelangen, kann ein Angreifer die LOAD_FILE Funktion von MySQL nutzen. MySQL kann über das Dateisystem auf Dateien zugreifen, auch wenn diese nicht über HTTP erreichbar sind. Ein Angreifer kann so Zugriff auf vermeintlich sichere Inhalte bekommen Manipulation von Daten Angreifer manipulieren Daten aus unterschiedlichen Beweggründen. In den meisten Fällen erhoffen sie sich durch die Manipulation an Informationen zu gelangen oder einen Login zu umgehen. Oftmals wird auch Schadcode eingeschleust, der nicht die Webanwendung selbst als Ziel hat, sondern ihre Benutzer Authentifizierung umgehen Versucht ein Angreifer eine Authentifizierung zu umgehen, wird oft auch von einem Authentication Bypass gesprochen. SQL-Injections werden in vielen Fällen für ein solches Vorgehen genutzt. Viele Anwendungen verfolgen die gleiche oder eine ähnliche Strategie, wenn Benutzer in der Anwendung eingeloggt werden sollen. Als erstes übermittelt der Benutzer über ein Formular seinen Benutzernamen und sein Passwort. Die übermittelten Daten werden anschließend mit der Datenbank abgeglichen. Wird eine entsprechende ID gefunden, auf welche die Daten zutreffen ist der Benutzer verifiziert. Meist wird noch ein Cookie gesetzt, das den Benutzer auf den Folgeseiten eindeutig identifiziert, damit er sich nicht auf jeder Seite erneut einloggen muss. SELECT id FROM benutzer WHERE name = $_GET[ name ] AND password = $_GET[ password ] ; Da die vom Benutzer übermittelten Daten weder geprüft noch anderweitig verifiziert werden kann eine Injection stattfinden. Übermittelt der Angreifer den Benutzernamen Admin und anstelle eines gültigen Passworts die Zeichenkette foo OR 1 = 1, erhält der Angreifer eine gültige ID, womit er als Administrator eingeloggt wäre. Das SQL-Statement sieht nun folgendermaßen aus 24 : 23 vgl. [APACHE] 24 vgl. [HEIDERICH et. al 2009, S. 529]

36 27 SELECT id FROM benutzer WHERE name = Admin AND password = foo OR 1 = 1 ; Durch die Übermittlung der bereits genannten Zeichenkette bricht der Angreifer aus den vorgegebenen Hochkommata aus und kann anschließend eigenen SQL- Code zur Ausführung bringen. Die Datenbank prüft nun, ob es einen Benutzer mit dem Namen Admin und dem Passwort foo gibt, oder ob die Zeichenkette 1 der Zeichenkette 1 entspricht. Da der Vergleich TRUE ergibt, wird ein valider Datensatz aus der Datenbank ausgegeben, der Angreifer hat sich also ohne Kenntnis eines Passwortes eingeloggt. Ein Authentication Bypass ist auch ohne das Ausbrechen aus den Hochkommata möglich. Je nach Konfiguration des Datenbanksystems und der Anwendung kann sich ein Angreifer einen Login erschleichen. Hierzu erstellt sich der Angreifer einen neuen Benutzeraccount, der dem des Administrators (oder des zu stehlenden Accounts) enorm gleicht. Lautet der Benutzername des Administrators z.b. Admin, erstellt der Angreifer einen neuen Benutzer, der Admin x lautet. Ist das Feld der Datenbank beschränkt, werden beim speichern des Datensatzes oft Zeichen abgeschnitten. Der Benutzername lautet danach z.b. Admin. Loggt sich der Angreifer mit dem Benutzernamen ein, erhält er die Berechtigungen des wahren Administrators, da bei dem Vergleich der Benutzernamen die Leerzeichen ignoriert werden 25. Damit dieser Angriff erfolgreich ist, müssen jedoch die Voraussetzungen stimmen. Das Datenbanksystem muss so konfiguriert sein, dass es überlange Zeichenketten kürzt und der Vergleich beim Login muss Leerzeichen am Ende des Benutzernamens ignorieren. Bei der Vielzahl von Webanwendungen kann ein Angreifer davon ausgehen, dass der Versuch irgendwann erfolgreich sein wird DoS (Denial of Service) Denial of Service 26 ist ein Angriff auf einen Rechner (meist einen Server), der dessen Unerreichbarkeit zur Folge hat. Ein DoS-Angriff kann verschiedene Ausprägungen haben und auf verschiedene Serverdienste zielen. Handelt es sich um eine größere Zahl von Angreifern, wird von DDoS (Distributed Denial of Service) gesprochen. Ein vielen Fällen ist der Dienst des Webservers (z.b. der Apache Webserver) das Ziel eines DoS-Angriffs, aber auch der MySQL-Server kann Opfer eines solchen Angriffs werden. Ein DoS-Angriff auf den MySQL-Server einer Webanwendung, kann durch eine 25 vgl. [HEIDERICH et. al 2009, S. 530] 26 engl. für Dienstverweigerung

37 28 simple SQL-Injection ausgelöst werden 27 : SELECT preis, beschreibung FROM artikel WHERE art-nr LIKE % UNION SELECT benchmark( , MD5("benchmark")), NULL -- ; Diese Injection nutzt die in MySQL integrierte Funktion benchmark. Die Funktion wiederholt die Anweisung in den Klammern so oft wie angegeben. In diesem Beispiel wird mal der String benchmark in einen MD5-Hash umgerechnet. Ein durchschnittlicher SQL-Server kann damit an seine Leistungsgrenzen gebracht werden. Schleust der Angreifer diese Injection mehrfach ein, oder handelt es sich um einen DDoS-Angriff, kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass der MySQL-Server keine weiteren Anfragen mehr bearbeiten kann. Je nach Konfiguration des Betriebssystems zieht die hohe Last auch andere Dienste in Mitleidenschaft Übernahme der Anwendung / des Servers Gelingt es einem Angreifer durch eine SQL-Injection das Administratorpasswort der Anwendung auszuspähen, kann er sich anschließend als Administrator einloggen und hat Kontrolle über die gesamte Anwendung. Für einen solchen Angriff muss das Passwort nicht im Klartext vorliegen. Ein MD5 gehashtes Passwort kann der Angreifer mit verschiedenen Rainbow-Tables 28 abgleichen oder auch selber durch Brute-Force versuchen den Hash selbst zu errechnen. War der Administrator nachlässig (z.b. nur ein sechs-stelliges einfaches Passwort) hat der Angreifer den Passwort innerhalb kurzer Zeit im Klartext vorliegen. Das Ziel eines Angriffs muss nicht immer die Webanwendung selbst sein. Ein Angreifer kann eine Injection ebenfalls dazu nutzen, den kompletten Server unter seine Kontrolle zu bringen. Damit dies geschehen kann, muss der MySQL-Server so konfiguriert sein, dass Dateien im Dateisystem gelesen und auch geschrieben werden können. Nach der Standardinstallation ist diese Option deaktiviert, der Angreifer muss also vorher herausfinden, ob bei dem MySQL-Server die Option trotzdem aktiviert ist. Ist dies der Fall, kann der Angreifer über eine SQL-Injection Dateien auf dem Server lesen und erstellen. Je nach Konfiguration des Webservers kann der Angreifer in vorhandene Shellscripts (z.b. in Crontabs) eigene Informationen einschleusen die dann vom Server ausgeführt werden. Durch die Lesemöglichkeit ist es ebenfalls möglich, an das MySQL-Passwort der Webanwendung zu gelangen. Dieses Passwort liegt meist in einer Config-Datei im Klartext vor. 27 vgl. [HEIDERICH et. al 2009, S. 533] 28 engl. für Regenbogen-Tabelle = Passwortlisten

38 Header-Injections Neben SQL-Injections stellen Header-Injections eine weitere Sicherheitslücke dar. Ein Angriff mittels Header-Injection richtet sich meist gegen die in PHP integrierte mail()-funktion, deren Aufgabe es ist Mails zu versenden. Der Angriff hat nicht primär die Webanwendung als Ziel, sondern nutzt diese nur, um die Webanwendung für eigene Zwecke zu missbrauchen, in diesem Fall für den Versand von SPAM-Mails. Der Versand von s über die mail()-funktion ist sehr simpel 29 : mail("support@example.com", "Support", $_POST[ nachricht ], "From:".$_POST[ mail ]); Diese einfache Code-Zeile versendet eine an die Adresse support@example.com mit dem Betreff Anfrage. Die versendete Text, sowie die Absenderadresse werden über die Variablen nachricht und mail entgegengenommen. Die versendete Mail würde etwa so aussehen 30 : From: mail@angreifer.de To: support@example.com Subject: Support Date: Tue, 31 May :38: Hallo, ich bin die Originalmail! Über die ohne Prüfung entgegengenommene -Adresse des Absenders, wird die Funktion für Header-Injections anfällig. Durch Eingabe von speziellen Zeichen, kann der Angreifer die Funktion so manipulieren, dass eine zweite Mail versendet wird, deren Daten vom Angreifer beliebig angegeben werden können. Anstelle einer korrekten Absenderadresse könnte der Angreifer folgenden Code eingeben 31 : spam@spam.com\r\nto: opfer@example.com\r\n BCC:opfer2@example.com, opfer3@example.com\r\n Subject: Spam Betreff\r\nSpam Nachricht\r\n.\r\n Diese kleine Codezeile schleust eine zweite Mail vor die eigentliche Mail ein 32 : 29 vgl. [PHP 2009(11)] 30 vgl. [KUNZ ESSER 2008, S. 66] 31 vgl. [KUNZ ESSER 2008, S. 66] 32 vgl. [KUNZ ESSER 2008, S. 66]

39 30 From: To: BCC: Subject: Spam Betreff Spam Nachricht. From: To: Subject: Support Date: Tue, 31 May :38: Hallo, ich bin die Originalmail! Wie zu sehen ist, wurde die Spam-Mail vor die eigentliche Mail eingeschleust und versendet Blind-Copies an mehrere Empfänger. Handelt es sich bei dem Angreifer um einen Bot 33, kann die Mail an mehrere Tausend Adressaten versendet werden. Die Webanwendung wird zum Massenspammer. Die Folgen für die Anwendung und den Server können verheerend sein, da durch einen solchen Spamversand die IP des Servers sehr schnell auf einer so genannten Blacklist landen. Viele Mailserver nehmen solche Mails anschließend nicht mehr an, was natürlich auch die legitimen Mails der Webanwendung betreffen würde. Provider nehmen in diesem Fall oft den Server vom Netz, somit wäre die Anwendung nicht mehr erreichbar. 3.5 NULL-Byte-Injections NULL-Byte-Injections stellen unter anderem eine Möglichkeit dar, dass ein Angreifer eigenen PHP-Code zur Ausführung in der Webanwendung bringt. Bei einer solchen Sicherheitslücke wird auch von Remote Command Execution gesprochen 34. Viele Webanwendungen nutzen include()- und require()- Anweisungen, um dynamisch PHP-Code oder Seiteninhalte zu laden. Die Werte 33 automatisiertes Script 34 vgl. [KUNZ ESSER 2008, S. 59]

40 31 stammen oftmals aus der URL und der Wert des GET-Parameters wird in der include()-anweisung genutzt 35 : //URL //Code <?php include($_get[ seite ]);?> Da die Anweisung die einzufügende Seite ungeprüft vom Benutzer übernimmt, kann ein Angreifer anstelle von start.php eine URL zu einer Datei angeben, die auf einem fremden Server liegt. Ist die PHP-Option allow_url_fopen oder allow_url_include 36. Da viele Programmierer die Gefahr einer solchen Sicherheitslücke kennen, belegen sie die include()-funktion mit einem Wert vor, der dann an den vom Benutzer übergebenen Wert angehängt wird 37 : //URL <?php include( includes/.$_get[ seite ].php);?> Das simple Ändern von start z.b. in würde nun nicht mehr funktionieren. Selbst fortgeschrittene Programmierer halten diese Methode für sicher, übersehen dabei aber die NULL-Byte-Problematik (NULL-Byte zeigt das Fehlen eines Wertes an) 38 : //URL seite=../../../etc/passwd%00 <?php include( includes/../../../etc/passwd%00.php );?> 35 vgl. [KUNZ ESSER 2008, S. 59] 36 bei der Standardinstallation aktiviert 37 vgl. [KUNZ ESSER 2008, S. 59] 38 vgl. [KUNZ ESSER 2008, S. 60]

41 32 Die Zeichenkette %00 bezeichnet ein hexadezimales NULL-Byte. Übergibt der Angreifer diesen Wert an die Anwendung kann er darauf hoffen, dass die Anwendung die Datei passwd 39 mittels der include()-anweisung einfügt, da alle eventuell vorhandenen Zeichen nach einem NULL-Byte ignoriert werden. Das Anhängen von.php ist in diesem Fall vollkommen ohne Wirkung. Erlaubt die Anwendung den Benutzern den Upload eigener Dateien, kann der Angreifer ebenfalls auf eine solche Datei verweisen. Kommt der Inhalt der Datei zur Ausführung, kann der Angreifer im schlimmsten Fall den kompletten Server samt Webanwendung unter seine Kontrolle bekommen. 3.6 Cross-Site Scripting Unter Cross-Site Scripting versteht man das Ausführen von JavaScript auf einer Domain, obwohl es von einer anderen Domain geladen wurde. Das Ziel des Angriffs ist nicht primär die Webanwendung, sondern ihre Benutzer. Im Browser des Benutzers soll dann das eingeschleuste JavaScript ausgeführt werden. Aufgrund dieser Problematik wird XSS von vielen Programmieren unterschätzt, da auf den ersten Blick die Anwendung nicht das Ziel des Angriffs ist. Jedoch besteht auch für die Anwendung eine nicht zu unterschätzende Gefahr, weshalb XSS sehr ernst genommen werden muss. Man kann bei XSS grundlegend zwischen drei verschiedenen Angriffsarten unterscheiden: 1. Reflektive Angriffe Persistente Angriffe Lokale Angriffe 42 Im Folgenden werden diese Angriffsarten näher beschrieben Reflektive Angriffe Von einem reflektivem Angriff wird gesprochen, wenn der vom Angreifer an den Server übermittelte Schadcode von diesem in der Antwort direkt wieder an den Benutzer zurückgesendet wird. Der übermittelte Schadcode wird von der Webanwendung nicht gespeichert. 39 Informationen über Linux-Benutzerkonten, inkl. Passwörter 40 vgl. [HEIDERICH et. al 2009, S. 476ff] 41 vgl. [HEIDERICH et. al 2009, S. 484ff] 42 vgl. [KUNZ ESSER 2008, S. 104ff]

42 33 In vielen Webanwendungen ist eine Suchfunktion integriert, um den Benutzern das Finden von Seiten und anderem Material zu erleichtern. Oftmals wird dabei der gesuchte Begriff dem Benutzer wieder angezeigt. Folgendes Beispiel soll die Vorgehensweise eines reflektiven Angriffs, unter Verwendung einer unzureichend gesicherten Suche, verdeutlichen. In diesem Beispiel wird die Suchfunktion über ein HTML-Formular bereitgestellt, das über GET die Parameter weiter gibt. Die erzeugt URL könnte dabei so aussehen: Hier wurde von dem Benutzer nach dem Begriff harmlos gesucht. Um zu testen ob die Suchfunktion anfällig für XSS ist, kann ein Angreifer einfach den Begriff <script>alert( XSS )</script> eingeben suchbegriff=<script>alert( XSS )</script> Zeigt die Suche anschließend eine JavaScript-Meldung mit dem Inhalt XSS an, ist die Suchfunktion anfällig für XSS, da HTML und JavaScript offensichtlich nicht gefiltert werden. Dies stellt den Idealfall für einen Angreifer dar, er kann nun auch JavaScript von einer anderen Domain nachladen: <script src=" <script src=" lädt die Datei xss.js von der Domain angreifer.com in die Webseite. In der Datei kann beliebiges JavaScript stehen, das im Browser des Benutzers ausgeführt wird. Der Cross-Site Scripting Angriff ist komplett. Ein unerfahrener Benutzer wird zu Recht die Frage stellen, welchen Sinn ein Angriff hat, der anschließend im Browser des Angreifers wieder ausgeführt wird. Natürlich gilt der Angriff nicht dem Angreifer selbst, sondern anderen Benutzern, die ihrerseits den Angriff ausführen, ohne davon zu wissen. Der Angreifer muss den ahnungslosen Benutzer nur dazu bringen, auf einen präparierten Link zu klicken. Damit der Angriff für das Opfer nicht zu offensichtlich ist, nutzen Angreifer gerne tinyurl.com 44. TinyURL.com ist ein Webservice, der lange Domains und Links in kleinere URL s umwandelt. Aus der oben genannten Adresse wird zu einem kleinen und unscheinbaren Link: Ein 43 vgl. [HEIDERICH et. al 2009, S. 477] 44 vgl. [TINYURL 2009]

43 34 Benutzer hat so keine Möglichkeit mehr zu erkennen, was sich hinter dem Link verbirgt. Um die Benutzer anschließend dazu zu bringen auf den präparierten Link zu klicken, bedarf es keiner großen Anstrengung. Ein einfacher Post 45 auf Twitter 46 oder in einem Blog mit der Meldung Don t click reicht aus, um die Neugier von tausenden von Benutzern zu wecken Persistente Angriffe Im Gegensatz zu reflektivem XSS wird persistentes XSS auf dem Server der Webanwendung gespeichert und bei jedem Aufruf der jeweiligen Seite ausgegeben. Für den Angreifer bietet ein persistenter Angriff den entscheidenden Vorteil, dass keine Aktion eines Benutzers erfolgen muss um den Angriff zu starten 48. Trotz der Gefahren, die durch XSS ausgehen, wird eine Prüfung bei vielen Webanwendungen von den Entwicklern vernachlässigt, oder komplett außer Acht gelassen. Blogs, Foren und Onlineshops sind in besonderem Maße betroffen. Blogs sind durch Kommentar-, Trackbackfunktionen und Dritterweiterungen oft für XSS anfällig. Foren gehören auch zu den sehr anfälligen Webanwendungen, da Benutzer über BBCode, und je nach Konfiguration, eigenes HTML nutzen dürfen. Die Vorgehensweise eines persistenten Angriffs ist der Vorgehensweise eines reflektiven Angriffs sehr ähnlich. Der Angreifer versucht z.b. über einen Kommentar in einem Blog JavaScript zur Ausführung zu bringen. Da die Kommentare in einer Datenbank gespeichert werden, wird der manipulierte Eintrag jedem Benutzer anzeigt, der die entsprechende Seite aufruft. Schafft es der Angreifer auf einem gut besuchten Blog JavaScript einzuschleusen, sind oft tausende Besucher von der Scripting Attacke betroffen Lokale Angriffe Lokale XSS Angriffe ähneln reflektiven Angriffen, zeichnen sich aber durch die Systematik aus, dass das Backend der Webanwendung (also die Scripte) bei dem Angriff nicht beteiligt ist. Der Angriff wird lediglich Clientseitig ausgeführt, ein Angreifer kann so eventuell implementierte Schutzmaßnahmen umgehen. Übernimmt ein Script in einer HTML Seite ungeprüft einen Wert aus der URL, kann 45 engl. to post = einen Beitrag verfassen 46 vgl. [TWITTER 2009] 47 vgl. [TWITTER 2009(2)] 48 vgl. [HEIDERICH et. al 2009, S. 484ff]

44 35 sich ein Angreifer dieses Verhalten zunutze machen. Amit Klein beschreibt auf webappsec.org, wie ein solcher Angriff aussehen kann 49 : "<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.url.indexof("name=")+5; document.write(document.url.substring(pos,document.url.length)); </SCRIPT> <BR> Welcome to our system... </HTML> Normally, this HTML page would be used for welcoming the user, e.g.: However, a request such as: <script>alert(document.cookie)</script> would result in an XSS condition." In diesem Beispiel übernimmt das Script aus der HTML-Datei ungeprüft einen vom Benutzer übermittelten Wert und schreibt diesen Wert dynamisch in das Dokument. Wird anstelle eines harmlosen Strings eine JavaScript-Anweisung übermittelt, wird diese anschließend ausgeführt XSS-Syntax Von einem Angreifer kann XSS in den verschiedensten Ausführungen in eine Webanwendung eingeschleust werden. Nicht immer sind XSS-Attacken so offensichtlich wie in den bereits gezeigten Beispielen. Ein versierter Angreifer versteht es, JavaScript auch mit anderen Methoden erfolgreich einzuschleusen. Normalerweise wird JavaScript folgendermaßen in Webseiten eingebettet: 49 vgl. [KLEIN 2005]

45 36 <script>alert(document.cookie)</script> Dieses kurze Script gibt eine Meldung mit sämtlichen Cookies und deren Inhalten aus, die aktuell im Browser des Benutzers von der aktuellen Domain gespeichert sind. Scripte können aber nicht nur gekapselt im script-tag ausgeführt werden, sondern auch in Attributen: <body onload="alert(document.cookie)"> Normalerweise wird das body-tag in einem Dokument nur einmal geöffnet. Die meisten aktuellen Browser interpretieren ein weiteres body-tag trotzdem und führen das enthaltene JavaScript ohne Rückfrage aus. Setzt die Anwendung einen Filter ein, der script- und body-tags oder gar HTML komplett verbietet, kann JavaScript über Umwege trotzdem ausgeführt werden. Wie bereits in angesprochen, erlauben viele Blogs und Foren die Nutzung von BB-Code, über den Benutzer unter anderem Bilder einbetten können. Die übermittelte Bildadresse wird von der Anwendung anschließend in das src-attribut des img-tags geschrieben. Prüft die Anwendung nicht, ob es sich bei der übermittelten Adresse tatsächlich um ein gültiges Bild handelt, kann ein Angreifer JavaScript anstelle einer Adresse übermitteln: <img src="javascript:alert(document.cookie)"> Diese Konstruktion wird zwar nur vom Internet Explorer ausgeführt, da er aber noch immer sehr weit verbreitet ist, sind viele Benutzer davon betroffen. Auch andere Attribute können Angreifern für das Einschleusen von JavaScript dienen, der Internet Explorer interpretiert JavaScript auch in style-attributen und sogar style-tags 50 : "<DIV STYLE="background-image: url(javascript:alert( XSS ))"> <DIV STYLE="background-image: url(javascript:alert( XSS ))"> <STYLE>.XSS{background-image: url("javascript:alert( XSS )") ;}</STYLE><A CLASS=XSS></A>" Die gezeigten Beispiele decken nur einen kleinen Teil der vielen Möglichkeiten ab, XSS in eine Webanwendung einzuschleusen. Über Formulare und andere HTML-Konstrukte ist es einem Angreifer ebenfalls möglich, JavaScript in eine Anwendung einzuschleusen. Alle Möglichkeiten aufzulisten, würde den Rahmen dieser Ausarbeitung sprengen. Auf der Seite wurden von einem Sicherheitsexperten viele weitere Angriffsmöglichkeiten zusammengetragen vgl. [KUNZ ESSER 2008, S. 93] 51 vgl. [RSNAKE 2009]

46 Folgen von Cross-Site Scripting Nachdem in den vorherigen Kapiteln verschiedene XSS-Arten und die XSS-Syntax vorgestellt wurden, werden jetzt die Folgen von XSS näher betrachtet Logindaten ausspähen / Sessiondiebstahl Viele XSS-Angriffe sollen Logindaten von Benutzern ausspähen, damit der Angreifer anschließend mit diesen ausgespähten Daten Zugriff auf die Webanwendung verschaffen kann. Um an diese Logindaten zu gelangen, kann der Angreifer verschiedene Wege wählen. Eine Möglichkeit besteht einen Keylogger einzusetzen, der die Benutzerdaten speichert, wenn der Benutzer einen Loginversuch unternimmt. Dazu muss es der Angreifer jedoch schaffen ein Script auf einer Seite mit Loginformular einzuschleusen. Ist dies nicht möglich, bleibt dem Angreifer noch die Option, das Cookie des Benutzers zu stehlen. Da viele Webanwendungen oftmals das gehashte Passwort und der Benutzer-ID als Identifikationsmerkmal in das Cookie setzen, kann der Angreifer diese Daten abgreifen. 52 Das Passwort kann er anschließend mit einer Rainbow-Table abgleichen oder selber versuchen den Hash zu errechnen. Hat der Benutzer ein kurzes Passwort im Einsatz (weniger als 8 Stellen), ist die Wahrscheinlichkeit hoch, dass dem Angreifer innerhalb kurzer Zeit das Passwort in Klartext vorliegen wird. Setzt die Anwendung Sessions für die Identifikation ein, kann ein Angreifer diese aus dem Cookie auslesen. Hat der Angreifer ebenfalls einen Account bei der Webanwendung, kann er die erspähte Session einfach mit seiner austauschen und ist anschließend als völlig anderer Benutzer angemeldet. Auch Administratoren der Anwendung können von diesem Session- oder Logindiebstahl betroffen sein. So kann ein Angreifer die Kontrolle über die komplette Anwendung erlangen Request Forgery Bei einem Request Forgery setzt der Benutzer ungewollt einen Request ab, der eine Reaktion der Anwendung zu Folge hat. Hat der Angreifer ein solches Script in die Anwendung eingeschleust, kann er beliebige Benutzeraktionen ausführen lassen, ohne dass der betroffene Benutzer den Request bemerkt. Ein Beispiel für eine solche Attacke ist der MySpace 53 Wurm Samy. Um mehr Freunde auf MySpace zu erhalten, schleuste ein MySpace Benutzer einen JavaScript Wurm auf MySpace ein. Rief ein Benutzer eine manipulierte Seite auf, fügte er damit den 52 vgl. [KUNZ ESSER 2008, S. 90ff] 53 vgl. [MYSPACE 2009]

47 38 Autor des Wurms automatisch zu seiner Freundesliste hinzu. Außerdem nistete sich der Wurm in dem Profil de Benutzers ein. Aufgrund dieser Systematik verbreitete sich der Wurm exponentiell. Der Autor hatte innerhalb weniger Stunden mehr als eine Millionen neue Freunde. Um die Verbreitung zu stoppen, musste MySpace für einige Stunden den Betrieb einstellen 54. An diesem Beispiel lässt sich sehr gut nachvollziehen, dass XSS nicht nur ein Problem der Benutzer ist, sondern auch ein großes Problem der Webanwendungen. 3.7 Cross-Site Request Forgery Cross-Site Request Forgery wird häufig unter XSS betrachtet, dabei handelt es sich jedoch um eine völlig andere Angriffsart. Wird bei XSS eine Anwendung dazu missbraucht, JavaScript im Browser des Benutzers auszuführen, wird bei CSRF der Browser des Benutzers genutzt, um auf einer anderen Seite Request im Namen des Benutzers auszuführen. Da CSRF vielen Programmierern und Webmastern noch weniger bekannt ist als XSS, findet sich diese Lücke in sehr vielen Webanwendungen Ablauf eines Cross-Site Request Forgeries Das nachfolgende Beispiel soll verdeutlichen, wie ein CSRF-Angriff abläuft. Bevor ein Angreifer mit der Attacke beginnen kann, muss er zunächst Informationen über das Opfer und dessen Aktivitäten einholen. In diesem Beispiel konnte der Angreifer in Erfahrung bringen, dass sein Opfer aktiv in einem Webforum mitliest und das Onlinebanking seiner Bank nutzt. Das Ziel des Angreifers ist es, eine Anfrage im Namen des Opfers an die Bank zu senden, um so eine Überweisung auf sein Konto vornehmen zu lassen. Auf der Webseite der Bank wird eine Überweisung mittels GET 55 vorgenommen 56 : betrag=250&zielkonto= Zur Vereinfachung wird auf weitere Parameter in der URL verzichtet, das Prinzip bleibt natürlich dasselbe. Wird die o.g. URL aufgerufen prüft das Script zunächst, 54 vgl. [KAMKAR 2005] 55 Sicherheitsrelevante Informationen werden beim Onlinebanking normalerweise per POST übertragen. Zur Vereinfachung wird in diesem Beispiel GET verwendet 56 vgl. [HEIDERICH et. al 2009, S. 506]

48 39 ob der Benutzer angemeldet ist (in diesem Falle wird ein Session-Cookie genutzt). Ist dies der Fall, wird eine Überweisung auf das Konto mit dem Betrag 250 vorgenommen. Da der Login bei dem Onlinebanking nur mittels Benutzernamen und Passwort möglich ist, kann ein Angreifer auf den ersten Blick keine Überweisung im Namen des Benutzers tätigen, ohne die Anmeldedaten zu kennen. Hier kommt nun CSRF zum Zuge. Da der Angreifer die URL-Parameter bei einer Überweisung kennt, setzt er in dem Forum eine Antwort ab, in der sich ein präparierter img-tag befindet 57 : <img src=" betrag=250&zielkonto= " /> Bei jedem Aufruf der Seite sendet der Browser eine Anfrage an den Bankserver, um das Bild abzurufen. Da es sich bei der URL offensichtlich um keine gültige Bilddatei handelt, sehen die Besucher des Forums je nach Browser, gar kein Bild oder nur ein kleines x. Die meisten Besucher des Forums besitzen kein Konto bei der Bank, nutzen das Onlinebanking also nicht. Dies sieht beim Opfer des Angriffs nicht wesentlich anders aus, auch dort wird kein Bild angezeigt. Ein Unterschied besteht allerdings, da das Opfer ein Kunde der Bank ist und zu dem Zeitpunkt beim Onlinebanking angemeldet ist. Der Browser sendet eine Anfrage an die Bank und sendet architekturbedingt sämtliche Cookies mit. Das Onlinebanking überprüft, ob der Benutzer eingeloggt ist. Da der Benutzer sich nicht korrekt abgemeldet hat, ist der Login noch gültig. Das Überweisungsscript kann nicht unterscheiden, ob der Aufruf vom Benutzer absichtlich getätigt wurde, oder ob er von einem präparierten img-tag stammt. Die Überweisung auf das Konto des Angreifers wird deshalb ohne Probleme ausgeführt. Dieses Beispiel verdeutlicht die enorme Gefahr, die von CSRF ausgeht. Der Angreifer konnte ohne mit dem Opfer in Kontakt zu treten die Attacke starten, die einzige Spur ist das Posting im Forum. Editiert der Angreifer den Post anschließend, oder nutzte er einen Proxyserver, kann er sich der Verfolgung sehr leicht entziehen. Der oben beschriebene Angriff ist natürlich nicht nur gegen Onlinebanking erfolgreich (das normalerweise zu den wenigen Webanwendungen gehört, die schon gegen CSRF gesichert wurden), die Methode funktioniert bei allen ungesicherten Anwendungen. Ein Angreifer kann dann im Namen des Benutzers beliebige Aktionen durchführen, seien es neue Posts in einem Forum, Mails über eine Schnittstelle versenden, etc. 57 vgl. [KUNZ ESSER 2008, S. 113], [HEIDERICH et. al 2009, S. 506]

49 Gefahren für das Intranet Durch CSRF können nicht nur Requests auf Webseiten abgesetzt werden, sondern auch Requests auf Seiten im Firmeninternen Netzwerk. 58 Oftmals verwenden Firmen freie Content-Management-Systeme oder freie Shopsysteme. Da der Angreifer bei Open Source Software die Struktur des Administrationsinterface sehr leicht in Erfahrung bringen, bestehen auch hier große Gefahren. Unter Umständen kann so ein komplettes Redaktionssystem von einem Angreifer verändert werden. Ein Benutzer kann ebenfalls als Mittelsmann missbraucht werden, um einen Angriff auf eine Drittseite durchzuführen. Die Möglichkeiten von CSRF in Kombination mit XSS sind fast unbegrenzt. 3.8 Datei-Uploads Dateiuploads gehören bei vielen Webanwendungen mittlerweile zum Standard. Foren erlauben ihren Benutzern oft den Upload von Bildern und Videos, aber auch von ZIP-Dateien oder anderen Archiven. Werden diese Dateien unzureichend geprüft, kann ein Angreifer unter Umständen den kompletten Server unter seine Kontrolle bringen, oder zumindest eine DoS-Attacke ausführen. PHP-Code kann hinter den Headerinformationen eines Bildes versteckt werden. Prüft die Anwendung das Bild, erhält sie einen korrekten Bild-Header und geht von einem gültigen Bild aus. Wird das Bild nicht per HTML sondern per include() eingebunden, wird der im Bild enthaltene PHP-Code ausgeführt. Anschließend kann der Angreifer über Funktionen wie eval() oder system() auf die Kommandozeile Zugriff nehmen und wichtige Einstellungen verändern. Einige Anwendungen erlauben den Upload von gepackten Dateien 59, die anschließend entpackt werden. Eine Textdatei mit dem Inhalt von einer Milliarde mal den Buchstaben A ist Zip-Komprimiert nur wenige KB groß, nach dem Entpacken jedoch ein Gigabyte 60. So kann ein Angreifer den Hauptspeicher und die Festplatte des Servers blockieren und eine hohe Last erzeugen, die zur Unerreichbarkeit des Servers führen kann. 58 vgl. [KUNZ ESSER 2008, S. 114] 59 z.b..zip oder.tar 60 vgl. [KUNZ ESSER 2008, S. 193]

50 41 4 Sicherungsmaßnahmen Nachdem im Kapitel 3 die Risiken ausführlich dargestellt wurden, werden in diesem Kapitel die Sicherungsmaßnahmen beschrieben, die zum Schutz von Webanwendungen ergriffen werden sollten. 4.1 Das Betriebssystem Bei der Wahl des Betriebssystems besteht generell die Wahl zwischen einem Windows- oder Unixsystem. Da sehr viele Extensions und Module Windows nur eingeschränkt unterstützen, sollte Unix als Betriebsystem zum Einsatz kommen. Auch kann über das Rechtesystem eine erweiterte Sicherheit hergestellt werden, die so auf Windows-Systemen nicht zur Verfügung steht. 4.2 PHP Im Kapitel 3.1 wurden architekturbedingte Risiken von PHP erläutert. Nachfolgend werden verschiedene Möglichkeiten vorgestellt, PHP selbst abzusichern Installation PHP kann bei der Installation in Verbindung mit dem Apache Webserver in zwei verschiedenen Modi installiert werden. Zum einen als Apache-Modul oder als CGI 1. Wird PHP als Apache-Modul installiert, ist PHP immer geladen, was der Geschwindigkeit sehr entgegenkommt. Bei einer Modulinstallation stehen auch zahlreiche weitere Optionen zur Verfügung. Kommt PHP als CGI zum Einsatz, wird bei jedem Scriptaufruf ein neuer Thread gestartet, was zur Folge hat, dass die Geschwindigkeit leidet. Allerdings kann bei der CGI-Installation PHP besser skaliert werden. Auch steht hier die Apache Sicherheitsoption suexec zur Verfügung die es erlaubt, PHP-Scripte für jeden virtuellen Host unter einem anderen Betriebssystembenutzer und einer anderen Gruppe ausführen auszuführen. So kann verhindert werden, dass Scripte eines 1 Common Gateway Interface

51 42 Benutzers auf Dateien eines anderen Benutzers zugreifen können. Sehr viele Risiken können durch diese Installationsart im Vorfeld schon ausgeschlossen werden. Viele Webhoster, die mehrere Kunden auf einem Webserver unterbringen, nutzen PHP als CGI Updates Da PHP wie jede andere Software auch von Bugs und Sicherheitslücken betroffen ist, die ein Benutzer nicht selber schließen kann, müssen regelmäßig Updates vorgenommen werden. Bevor jedoch Updates vorschnell installiert werden, sollte einige Zeit abgewartet werden, ob das neue Update nicht neue Sicherheitslücken oder Bugs mit sich bringt. Als Beispiel kann die Veröffentlichung von PHP herangezogen werden. Kurz nach Vorstellung des Updates wurde bekannt, dass die Option magic_quotes_gpc als aktiv angezeigt wird, obwohl sie tatsächlich deaktiviert ist. Die Option magic_quotes_gpc escaped automatisch einfache und doppelte Anführungszeichen, und bereitet vom User übergebene Werte für eine MySQL-Abfrage vor. Verlassen sich Programmierer auf diese Option, wird die Anwendung anfällig für MySQL-Injections. Da es sich um einen schwerwiegenden Fehler handelte, wurde die PHP Version nach kurzer Zeit zurückgezogen und eine Empfehlung ausgesprochen, auf PHP zu warten register_globals Wie in bereits beschrieben, bringt die Option register_globals durch die Umwandlung von GET- und POST-Requests in globale Variablen einige Sicherheitsrisiken mit sich, wenn Scripte Variablen nicht vorher initialisieren. Aus Abwärtskompatibilität zu älterer PHP-Software wird diese Option oftmals aktiviert. Seit der Version 5.3 ist diese Option als veraltet eingestuft und wird in PHP 6 entfernt 3. Aus diesen Gründen und Gründen der Sicherheit sollte die Option deaktiviert werden. So werden Programmierer auch gezwungen, vom Benutzer übergebene Werte über die jeweiligen GET- oder POST-Variablen zu verwenden allow_url_fopen / allow_url_include Entfernte Scripte und Dateien in die eigene Webanwendung zu integrieren, kann wie in beschrieben, zu Sicherheitslücken und unter Umständen zum Totalverlust des Servers samt Anwendung führen. Nutzt die Anwendung diese Optionen nicht, können die jeweiligen Direktiven abgeschaltet werden. Durch das 2 vgl. [PHP 2008] 3 vgl. [PHP 2009(7)]

52 43 Deaktivieren der Direktiven können Programmierer auch dazu gezwungen werden, andere Möglichkeiten für die Informationsübergabe von fremden Servern zu nutzen Safe Mode Der Safe Mode ist eine Sicherheitsoption die prüft, ob das aktuell ausgeführte Script auf Dateien von anderen Benutzern zugreift. 4 Ist das der Fall, wird der Zugriff blockiert. Allerdings kann es bei der Nutzung von verschiedenen PHP- Extensions zu Problemen kommen, da nicht alle Extensions den Safe Mode beachten. Auch kann es beim Dateiupload zu Problemen kommen, da die Dateien nach dem Upload (sofern dieser per HTTP und nicht per FTP erfolgt ist) nicht dem FTP-Benutzer des jeweiligen virtual Hosts gehören, sondern dem Webserver. Weitere Manipulationen können danach nur vom Webserver, also PHP selbst vorgenommen werden. Eine Lösungsoption könnte ein vom Benutzer root ausgeführter Crontab sein, der bei neuen Dateien automatisch die Benutzer- und Gruppenzugehörigkeit zu korrigieren Externe Sicherheitsmodule Um PHP abzusichern gibt es verschiedene Externe Module und Software, die frei zum Download angeboten werden. Viele dieser Module erweitern spezielle Funktionen und erlauben z.b. die Ausführung von Scripten mit anderen Berechtigungen 5. Ein sehr bekannter PHP-Patch ist der von Stefan Esser entwickelte Suhosin- Patch 6. Suhosin sichert PHP gegen Buffer-Overflows und String-Schwachstellen 7. Ebenfalls abgesichert werden Remote-Includes, NULL-Bytes und Header-Injections. Der Administrator kann auch bestimmte Funktionen sperren und so den Programmierer zwingen, andere Funktionen zu nutzen. 4.3 MySQL Grundsätzlich sollte die Webanwendung niemals mit dem MySQL root-account arbeiten. Gelingt einem Angreifer eine SQL-Injection, kann diese die komplette Datenbank- und Tabellenstruktur ändern und sogar neue Benutzer anlegen. Der 4 vgl. [PHP 2009(12)] 5 vgl. [MARSCHING 2008] 6 vgl. [ESSER 2007] 7 vgl. [NEWSHAM 2000]

53 44 Benutzer root sollte ausschließlich für die Konfiguration genutzt werden, jedoch nie in einem Produktivsystem. Für den Gebrauch in einer Webanwendung ist ein neuer Benutzer anzulegen, der nur Daten anzeigen und ändern darf (SELECT, INSERT, UPDATE, DELETE und unter Umständen noch FILE). Strukturänderungen (CREATE, ALTER, etc.) werden in der Regel von der Webanwendung selber nicht vorgenommen, weshalb dem Benutzer diese Rechte auch nicht zugewiesen werden sollten. Wie bei PHP sollte der MySQL Server ebenfalls regelmäßig geupdated werden um so die neuesten Sicherheitsfeatures und Bugfixes zu erhalten. 4.4 Apache-Webserver Bei dem Apache-Webserver sollten, wie bei PHP und MySQL, regelmäßig Updates eingepflegt werden, um so Bugfixes und neue Features zu erhalten. Für den Apache-Webserver stehen verschiedene Module zur Verfügung, die die Sicherheit erhöhen sollen. Ein sehr bekanntes Sicherheitsmodul für den Apache- Webserver ist mod_security. Laut Herstellerbeschreibung 8 ist mod_security eine Web Application Firewall. Das Modul kann mit verschiedenen Regeln ausgestattet werden und filtert anhand dieser Regeln den Datentransfer. Allerdings muss der Administrator diese Regeln selber erstellen, da das Modul zunächst keine umfassenden Regeln bereitstellt. Unerfahrene Administratoren können dadurch den Webserver in Gefahr bringen, wenn durch neue Regeln Sicherheitslücken erst entstehen. Jede Regel muss deshalb gründlich getestet werden, bevor sie auf dem Produktivsystem übernommen wird. Wie bei vielen Firewalls entstehen durch mod_security Performanceeinbußen. 4.5 SQL-Injections PHP stellt dem Programmierer einige vorgefertigte Funktionen zur Verfügung, mit denen vom Benutzer übergebene Variablen behandelt werden können, um die Anwendung vor SQL-Injections zu schützen Escaping Um zu verhindern, dass Angreifer einfache oder doppelte Anführungszeichen dazu benutzen, um aus dem MySQL-Statement auszubrechen, müssen die übermittelten Werte mit escaped werden. Dabei werden einfache und doppelte Anfüh- 8 vgl. [BREACH 2008]

54 45 rungszeichen, sowie der Backslash mit einem zusätzlichen Backslash maskiert. Folgende Funktionen können dafür verwendet werden: addslashes() 9 maskiert einfache und doppelte Anführungszeichen, den Backslash und das NULL-Byte. Der Backslash wird in der Datenbank gespeichert, nach dem Auslesen muss dieser mit der Funktion stripslashes() entfernt werden. mysql_real_escape_string() 10 maskiert, wie addslashes(), einfache und doppelte Anführungszeichen, das NULL-Byte, zusätzlich auch noch folgende Zeichen: \x00, \n, \r und \x1a. magic_quotes_gpc 11 Diese Option kann in der Konfigurationsdatei aktiviert werden und wendet die Funktion addslashes() automatisch auf die vom Benutzer übergebenen GET-, POST- und COOKIE-Werte an. Seit PHP 5.3 ist diese Einstellung veraltet und soll in der Version 6 entfernt werden. Unter besonderen Umständen ist es dem Angreifer trotz Escaping möglich, aus Anführungszeichen auszubrechen und eine SQL-Injection zu verursachen. Werden in der Datenbank die Character Sets big5, cp932, gbk oder sjis genutzt, kann der Angreifer die Anführungszeichen in Multibyte-Kodierung übergeben, anstelle von normalen Klartext. Die Multibyte-Zeichen werden von der Datenbank anschießend wie ein normaler Text behandelt wird. PHP erkennt diese Zeichen nicht, kann also kein Escaping vornehmen. Aus diesem Grund sollten die oben genannten Character Sets nicht verwendet werden Casting Erwartet die Anwendung einen numerischen Wert (z.b. int, float), wird dieser meist ohne Anführungszeichen im Datenbankstatement verwendet. Da der Angreifer in diesem Fall nicht aus bereits vorhandenen Anführungszeichen ausbrechen muss, muss er diese nicht mit übermitteln. Ein Escaping ist in diesem Fall vollkommen wirkungslos. Der Programmierer muss in diesem Falle eine Typenprüfung oder zumindest eine Typenkonvertierung 13 vornehmen, um SQL-Injections zu verhindern. PHP bietet für die Prüfung auf Zahlen eine vorgefertigte Funktion. is_numeric() prüft, ob die übergebene Variable eine Zahl ist 14. Alternativ kann der Programmierer bei der Zuweisung der Variable ein Casting vornehmen: 9 vgl. [PHP 2009(13)] 10 vgl. [PHP 2009(14)] 11 vgl. [PHP 2009(15)] 12 vgl. [HEIDERICH et. al 2009, S. 574] 13 Casting 14 vgl. [PHP 2009(8)]

55 46 $zahl = (int)$_post[ zahl ]; Hier erhält die Variable $zahl einen vom Benutzer per POST übergebenen Wert. Durch das Konstrukt (int) gibt der Programmierer eine zusätzliche Typenkonvertierung vor. Der PHP-Parser versucht die übergebene Variable in einen Integer- Wert umzuwandeln. Ist dies nicht möglich, erhält die Variable den Wert Blacklist-Filterung Einige Programmierer versuchen über Blacklists verschiedene Schlüsselworte zu filtern, damit diese nicht für eine SQL-Injection verwendet werden können. Allerdings müssen verschiedene Punkte beachtet werden. Zum einen darf der Filter nicht zwischen Groß- und Kleinschreibung unterschieden, Leerzeichen müssen ebenfalls ignoriert werden. Die gefilterten Wörter können durchaus auch in einer legitimen Übermittlung vorkommen, eine Filterung würde die Übermittlung zumindest teilweise verstümmeln. Auch können neue Angriffsmuster entwickelt werden, gegen die eine Blacklist wirkungslos wäre Prepared Statements Durch die relativ neue MySQL-Extension mysqli 15 besteht in PHP die Möglichkeit, Prepared Statements zu nutzen. Dabei bereitet ein Funktionsaufruf das MySQL-Statement vor, über eine zweite Funktion können dann Werte übergeben werden 16 : "[...] // Das Statement vorbereiten $stmt = mysqli_prepare($res, "INSERT INTO users VALUES (?,?,?,?)"); // Parameter daran binden mysql_bind_param($stmt, sssi, $name, $vorname, $ , $alter);" Bei diesem MySQL-Statement wird Architekturbedingt automatisch ein mysql_real_escape_string auf die übergebenen Werte angewendet. Injections können nicht eingeschleust werden. 15 vgl. [PHP 2009(4)] 16 vgl. [KUNZ ESSER 2008, S. 141]

56 Stored Procedures Seit MySQL 5.0 stehen Stored Procedures zur Verfügung. Dort können verschiedene Statements gespeichert werden. Der Programmierer kann über die Webanwendung auf diese Stored Procedures zugreifen. Da nur der Programmierer nicht auf die Tabellen selber zugreifen kann, sind Abfragen nur über die Stored Procedures möglich. Allerdings schützen Stored Procedures nicht automatisch vor SQL-Injections, auch hier muss auf eine korrekte Implementierung geachtet werden 17 : "CREATE PROCEDURE varchar(400)=null AS nvarchar(4000) = SELECT id, name, password FROM user WHERE name LIKE + EXEC (@query)" Diese Stored Procedure ist anfällig für SQL-Injections, da der Parameter suchstring direkt in das Query eingefügt wurde und nicht in der per EXEC übergeben wird. Eine leicht veränderte Syntax sichert die Procedure gegen SQL-Injections 18 : "CREATE PROCEDURE varchar(400)=null AS nvarchar(4000) = SELECT id, name, password FROM user WHERE name EXEC 4.6 Header-Injections Um die in 3.4 beschriebene Header-Injections zu verhindern, muss die vom Benutzer übermittelte Mailadresse auf eine korrekte Syntax geprüft werden. Dies kann mit einer Regular Expression erreicht werden 19 : 17 vgl. [HEIDERICH et. al 2009] S vgl. [HEIDERICH et. al 2009] S vgl. [KUNZ ESSER 2008, S. 67]

57 48 "preg_match("#^[$x]+(\.?([$x]+ \.)*[$x]+)? (([a-z0-9]+-*)?[a-z0-9]+ \.)+[a-z]{2,6}.?#", $_POST[ absender ])" Wird eine Zeichenkette übermittelt, bei der es sich nicht um eine -Adresse handelt, gibt die Funktion false zurück. Der Programmierer kann so sicherstellen, dass vom Benutzer keine Header-Informationen eingeschleust werden. Nach Möglichkeit sollte die mail()-funktion von PHP nicht direkt genutzt werden, sondern nur über eine Schnittstelle. Dazu gibt es im Internet Open Source Klassen, wie z.b. PHPMailer 20. Dort sind schon zahlreiche Sicherheitsfunktionen implementiert, die Schadhafte Eingaben erkennen. Der vom Benutzer übermittelte Betreff und Inhalt sollte ebenfalls auf XSS überprüft werden. Verschickt die Anwendung die Mails im HTML-Format, kann auch dort JavaScript ausgeführt werden. Deshalb sollten Benutzereingaben mit der PHP-Funktion htmlentities() behandelt werden. 4.7 NULL-Byte-Injections Damit Benutzereingaben gar nicht erst durch NULL-Bytes aus einer festgelegten Struktur ausbrechen können, sollten die übermittelten Werte nie ungeprüft Teil einer include()- oder file_get_contents()-funktion sein. Ein dynamisches Include kann über ein Array erreicht werden 21 : "<?php $files = array( page1.php, page2.php, page3.php ); if ( in_array($_get[ page ],$files) ) include ($_GET[ page ]); else echo Kein Zugriff erlaubt! ;?>" In diesem Konstrukt wird geprüft, ob der übermittelte Wert ebenfalls im Array vorhanden ist. Ist dies der Fall, wird die include()-funktion aufgerufen, ansonsten erhält der Benutzer eine Meldung, dass ein Zugriff nicht gestattet wurde. So kann auf einfache Weise verhindert werden, dass ein Angreifer eine Remoteoder Local-File-Inclusion vornehmen kann. 20 vgl. [WORX 2009] 21 vgl. [KUNZ ESSER 2008, S. 60]

58 Cross-Site Scripting erkennen und verhindern Um XSS zu verhindern sollten Benutzereingaben ausreichend gefiltert werden. Bei der Filterung spielt es zunächst keine Rolle, ob es sich um einen reflektiven oder persistenten Angriff handelt. Lediglich bei lokalen Attacken müssen andere Filter verwendet werden, da hier die Webanwendung komplett umgangen wird. Problematisch kann es ebenfalls werden, falls Benutzer HTML übergeben dürfen, z.b. über einen WYSIWYG-Editor 22. Wie verschiedene Filter greifen und wie diese eingesetzt werden sollten, wird nachfolgend beschrieben Kodierungen umwandeln und NULL-Bytes entfernen Bevor vom Benutzer übergebene Zeichenketten mit Filtern behandelt werden, sollten die Zeichenketten dekodiert werden. Wie beschrieben, kann ein Angreifer XSS auch mit Hilfe von kodierten Zeichenketten in die Anwendung einschleusen oder diese mit NULL-Bytes unkenntlich machen. Zunächst sollten NULL-Bytes entfernt werden. Dabei ist zu beachten, dass nicht nur reguläre NULL-Bytes, wie \0 entfernt werden, sondern auch exotischere Konstrukte, wie z.b. UTF-16 NULL-Bytes. Folgender Ausdruck entfernt UTF-16 NULL-Bytes: preg_replace( #(&\#x*)([0-9a-f]+);*#iu,"\\1\\2;",$source); Wurden alle NULL-Bytes entfernt, kann die Zeichenkette dekodiert werden. Dabei sollten Dezimal- und Hexadezimale Zeichen umgewandelt werden. preg_replace( /&#x([a-f0-9]+);/mei,"chr(0x\\1)", $source); Hier werden Hexadezimale Zeichen in Latin-Zeichen umgewandelt. Anschließend kann die so behandelte Zeichenkette weiter von PHP bearbeitet werden HTML entfernen Wenn Benutzer kein HTML übermitteln dürfen, sollten HTML-Tags entfernt, oder zumindest in ungefährliche Zeichen umgewandelt werden. PHP stellt dafür verschiedene Funktionen zur Verfügung. Zunächst sollte die Benutzereingabe mit strip_tags() 23 behandelt werden. $source = strip_tags($source); 22 What You See Is What You Get 23 vgl. [PHP 2009(16)]

59 50 Diese Funktion entfernt sämtliche HTML-Tags, wie <script> oder <body>. Anschließend ist es empfehlenswert, die noch verbliebenen potenziell gefährlichen Zeichen mit htmlentities() 24 umzuwandeln, mit der zusätzlichen Option ENT_QUOTES: $source = htmlentities($source, ENT_QUOTES); Die Option ENT_QUOTES sorgt dafür, dass einfache und doppelte Anführungszeichen in HTML-Entitäten umgewandelt werden. Aus " wird ". So kann ein Angreifer nicht durch verschachtelte Zeichen aus Anführungszeichen ausbrechen. Trotz Dekodierung ist es empfehlenswert bei der htmlentities()-funktion den Zeichensatz anzugeben. Dieser wird als zweite Option in der Funktion verwendet: $source = htmlentities($source, ENT_QUOTES, UTF-8 ); Zusätzlich sollte bei der anschließenden Ausgabe der Zeichensatz im Header mitgegeben werden, damit der Browser alle Zeichen korrekt darstellt HTML erlauben In vielen neuen Webanwendungen, wie Blogs und neueren Foren, soll der Benutzer HTML zur Formatierung seines Beitrags übermitteln dürfen. In diesem Fall kann die Eingabe nicht mit strip_tags() und htmlentities() behandelt werden. Viele Programmierer stehen deshalb vor dem Problem, wie HTML grundsätzlich erlaubt, Scripting aber verboten werden kann. Nachfolgend werden verschiedene Techniken aufgezeigt, wie dieser Anforderung begegnet werden kann BBCode BBCode 25 ist eine nicht standardisierte Auszeichnungssprache, die oft in Foren Verwendung findet 26. Die Syntax ist an HTML angelehnt, viele Elemente unterscheiden sich nur durch die Schreibweise. So formatiert [b]fett[/b] den Text fett, analog zur HTML-Schreibweise <b>fett</b>. Der Unterschied liegt hier lediglich in der Verwendung unterschiedlicher Klammern. Da Webbrowser BBCode als reinen Text darstellen, muss ein serverseitiges Script den BBCode parsen und durch HTML ersetzen. Da nur bekannter BBCode geparst wird, kann kein 24 vgl. [PHP 2009(17)] 25 Bulletin Board Code 26 vgl. [KUNZ ESSER 2008, S. 97]

60 51 zusätzlicher Code von einem Angreifer eingeschleust werden. Dieser würde nur als normaler Text im Browser ausgegeben werden und kann keinen Schaden anrichten. Die Stärke des BBCodes ist gleichzeitig jedoch der größte Nachteil. Im Vergleich zu HTML ist BBCode sehr unflexibel, komplizierte Konstrukte sind oft nicht möglich. Benutzer können nur begrenzt Attribute (wie z.b. Farbe oder Größe) vorgeben, ein erweitertes Styling von Elementen ist nicht möglich HTML-Filter In einigen neuen Webanwendungen sind WYSIWYG-Editoren integriert. Diese erlauben dem Benutzer Text in Echtzeit zu formatieren, ohne sich um BBCode oder HTML selbst zu kümmern. Diese Editoren übermitteln beim Absenden HTML an die Anwendung. In einigen Fällen kann der Benutzer zusätzlich den Code im Editor verändern und so selbst HTML übergeben. In diesen Fällen muss in der Webanwendung eine Filterfunktion vorhanden sein, die alle Eingaben des Benutzers überprüft. Bei HTML-Filtern gibt es zwei verschiedene Ansätze. Zum einen ist es die Blacklist-Prüfung, bei der gefährliche Elemente aus der Eingabe entfernt werden. Bei der Filterung werden anhand einer vom Administrator vorgegeben Liste Elemente entfernt. Der zweite Ansatz ist die Filterung mit einer Whitelist. Im Gegensatz zur Blacklist, bei der Elemente aufgrund einer Liste entfernt werden, werden bei einer Whitelist Elemente anhand einer Liste erlaubt, der Rest wird entfernt. Grundsätzlich ist die Whitelist-Filterung einer Blacklist vorzuziehen. Da bei einer Blacklist alle Angriffe bekannt sein müssen, damit der Filter greift, kann ein Angreifer, der einen neuen Ansatz verfolgt, ohne Probleme die Blacklist umgehen. Selten enthält eine Blacklist alle möglichen Angriffe, sie muss deshalb regelmäßig aktualisiert werden. Angreifer sind der Blacklist also immer einen Schritt voraus. Aus diesem Grund sollte der Whitelist-Ansatz verfolgt werden. Hier kann ein Angreifer auch durch neue Muster den Filter nicht umgehen, da alle nicht erlaubten Elemente von vorne herein gefiltert werden. Ein prominenter Whitelist-Filter ist der HTML Purifier 27. Anders als bei den meisten Filtern verwendet der HTML Purifier keine regulären Ausdrücke um HTML zu prüfen. Aus dem übermittelten HTML wird von dem Programm ein DOM 28 - Baum erstellt. Dort werden alle Tags, Attribute und Scripts entfernt, die nicht spezifiziert wurden. Anschließend wird aus dem DOM-Baum wieder HTML generiert und ausgeliefert 29. Leider benötigt der HTML Purifier durch seine komplexe Struk- 27 vgl. [YANG 2009] 28 Document Object Model 29 vgl. [YANG 2009(2)]

61 52 tur ein gewisses Maß an Rechenzeit. Um diesem Aspekt Genüge zu tragen, gibt es eine standalone Version, die die Geschwindigkeit erhöhen soll Lokale Angriffe verhindern Wie bereits beschrieben, wird das Backend der Webanwendung bei lokalen Angriffen umgangen, so dass die Eingaben gar nicht erst einen Filter durchlaufen. Soll deshalb eine HTML-Seite per JavaScript eine Information aus der URL übernehmen, muss dieser Wert ebenfalls validiert werden, bevor er weiterverarbeitet wird. Allerdings muss beachtet werden, dass JavaScript, im Gegensatz zu PHP, keine vorgefertigten Funktionen zur Prüfung von HTML anbietet. Diese Funktionen muss der Programmierer unter Zuhilfenahme von verschiedenen String-Funktionen selber erstellen. Da hier durchaus Fehler passieren können und gewisse Konstrukte nicht abgesichert sind (z.b. nicht geschlossene Tags), sollte auf ein lokales Übernehmen von Benutzerinformationen weitgehend verzichtet werden. Stattdessen kann die Seite mit den benötigten Informationen rekursiv aufgerufen werden, damit die übermittelten Informationen durch PHP geprüft werden können. 4.9 Cross-Site Request Forgery verhindern Da CSRF durch das Design der Webanwendung erst ermöglicht wird, ist es besonders aufwendig bereits vorhandene Anwendungen gegen solche Angriffe abzusichern. Im Folgenden werden verschiedene Schutzmechanismen vorgestellt, mit denen Webanwendungen gegen Angriffe gesichert werden können POST statt GET CSRF-Angriffe lassen sich sehr leicht über ein manipuliertes img-tag ausführen, wenn die Anwendung eine GET-Anfrage erwartet. Wird in der Anwendung nun POST anstelle von GET verwendet, um die Anfrage entgegenzunehmen, funktioniert der Angriff mit dem img-tag nicht mehr. Dies ist allerdings kein allumfassender Schutz gegen CSRF, dem Angreifer wird es lediglich etwas schwerer gemacht vgl. [KUNZ ESSER 2008, S. 116]

62 CAPTCHAS, Passwortabfrage und Bestätigungsmails CAPTCHAS 31 werden in vielen Webanwendungen zur Verifizierung eines menschlichen Benutzers verwendet. Sie sind oft in Foren bei der Registrierung zu finden um dort zu verhindern, dass Bots eine automatische Registrierung vornehmen und anschließend Spam posten. Diese CAPTCHAS können auch in anderen Bereichen der Webanwendung verwendet werden, um dort die feste Absicht zu verifizieren, dass der Benutzer auch tatsächlich die gewählte Aktion ausführen möchte. Da ein manipulierter img-tag in einem Forum den Inhalt des CAPTCHAS nicht kennen kann, ist die Anwendung in diesem Falle vor CSRF geschützt 32. Facebook 33 setzt diese Funktion flächendeckend ein. Ein Nachteil bei der Verwendung kann die Störung des Arbeitsflusses des Benutzers sein. Um einen umfassenden Schutz herzustellen, müsste bei fast jeder Aktion des Benutzers ein CAPTCHA zur Anwendung kommen, selbst beim Logout. Da dies nicht praktikabel ist, wird die Funktion oftmals nur bei sicherheitsrelevanten Teilen der Anwendung verwendet. CAPTCHAS können also nur als ein Mittel von vielen sein, um CSRF zu verhindern. Anstelle von CAPTCHAS kann auch das Passwort des Benutzers abgefragt werden. Der Sicherheitsgewinn ist derselbe wie bei dem Einsatz von CAPTCHAS. Bei hochsensiblen Teilen der Anwendung kann auch eine Bestätigungsmail zum Einsatz kommen. Möchte der Benutzer eine Aktion in diesem Teil der Anwendung ausführen, wird eine Bestätigungsmail versandt. Den Erhalt der der Mail muss der Benutzer bestätigen, meist durch einen in der Mail enthaltenen Link Einsatz von Token Die wohl sicherste Methode um CSRF zu verhindern, ist der Einsatz von Token. Die Funktion eines solchen Tokens ist relativ simpel. Nach dem Login in der Webanwendung erhält der Benutzer ein Session-Cookie, in dem der Token gespeichert wird. Gleichzeitig wird der Token an jeden Link angehängt und in jedes Formular als verstecktes Element eingefügt 34. Bei der Generierung muss darauf geachtet werden, dass ein Angreifer den Token nicht erraten kann. Deshalb sollte ein Hash-Wert aus Zufallszahlen und einem Salt-Wert verwendet werden, den der Angreifer nicht kennen kann. Klickt der Benutzer anschließend auf einen Link oder schickt er ein Formular 31 Meist eine Kombination aus Buchstaben und Zahlen, die als Bild angezeigt wird 32 vgl. [KUNZ ESSER 2008, S. 118] 33 vgl. [FACEBOOK 2009] 34 vgl. [HEIDERICH et. al 2009, S. 293ff]

63 54 ab, wird der per Cookie übermittelte Token mit dem per GET / POST übermittelten Token verglichen. Stimmen beide Werte überein, wird die gewählte Aktion ausgeführt, ansonsten erhält der Benutzer eine Fehlermeldung. Am Ende des Scripts wird ein neuer Token generiert, der den alten Token im Cookie ersetzt und ebenfalls wieder an alle Links angehängt wird. Versucht nun ein Angreifer z.b. per img-tag eine CSRF-Attacke, läuft diese ins Leere, da der Angreifer den Token nicht kennen kann. Abbildung 4.1: Token im Joomla-Quellcode Der Einsatz von Token schützt ebenfalls bei POST-Anfragen, so dass bei korrekter Verwendung keine CSRF-Attacke mehr möglich ist. Allerdings muss darauf geachtet werden, dass die Anwendung ebenfalls gegen XSS geschützt ist. Schleust ein Angreifer JavaScript in die Anwendung ein, kann er den Token aus dem Cookie, oder falls dies nicht möglich sein sollte (z.b. wegen der aktivierten Option http-only 35 ), aus dem Quelltext der HTML-Seite auslesen. Ein Schutz wäre in diesem Fall natürlich nicht mehr gegeben. 35 vgl. [PHP 2009(9)]

64 Tag-Überprüfung Die bisher vorgestellten Sicherungsmaßnahmen schützen die Anwendung vor CSRF. Damit sie aber nicht als Ausgangspunkt für einen Angriff auf einen Dritten genutzt werden kann, sollte vom Benutzer übermittelter Inhalt überprüft werden. Handelt es sich um ein Forum, sollten übermittelte img-tags des BBCodes auf ihre Korrektheit überprüft werden, damit dort nur URL s zu Bildern angegeben werden. Allerdings kann selbst diese Schutzfunktion einen erfahrenen Angreifer nicht davon abhalten, ein img-tag für einen Angriff zu missbrauchen, es wird ihm lediglich erschwert Datei-Uploads absichern Generell stellen Dateiuploads alleine noch keine Sicherheitslücke dar, erst die Weiterverarbeitung kann Risiken hervorbringen. Zunächst sollte der MIME-Type jeder hochgeladenen Datei überprüft werden und nicht nur die Dateiendung. Die PHP Bibliothek PECL 36 stellt dazu die Erweiterung Fileinfo zur Verfügung. Jedoch kann sich trotz korrektem MIME-Type in der Datei ausführbarer PHP-Code verstecken, der von den PHP-Dateifunktionen nicht erkannt wird. Deshalb sollten vom Benutzer hochgeladene Dateien nicht per include() oder require() eingebunden werden, da sonst eventuell vorhandener PHP-Code ausgeführt wird. Darf der Benutzer gepackte Dateien, wie z.b. ZIP-Dateien oder TAR-Archive, hochladen, müssen diese vor der Weiterverarbeitung durch einen Virenscanner überprüft werden. Erst wenn diese Überprüfung stattgefunden hat, kann die Datei ohne Gefahr entpackt werden Sichere Softwarearchitektur Sichere Webanwendungen zeichnen sich nicht nur durch das Schließen der wichtigsten Sicherheitslücken aus, sondern ebenfalls durch eine von Grund auf sichere Architektur. Deshalb muss schon in der Designphase auf zahlreiche Sicherheitsaspekte Acht gegeben werden, da eine spätere Änderung oft sehr aufwendig ist. Im Folgenden werden verschiedene Vorgehensweisen und Methoden erarbeitet, die für eine sichere Anwendung von großer Bedeutung sind. 36 vgl. [PECL 2008]

65 Preisgabe von Informationen Gibt die Webanwendung mehr Informationen heraus als eigentlich notwendig, können diese für einen Angreifer von großer Bedeutung sein. Das zugrunde liegende Prinzip nennt sich Security through obscurity. Durch Geheimhaltung und Verschleierung soll so Sicherheit erreicht werden. Die moderne Kryptologie nimmt zwar inzwischen Abstand von diesem Prinzip, bei der Erstellung und Konfiguration von Webanwendungen kann es als Ergänzung aber durchaus nützlich sein. Allerdings muss darauf hingewiesen werden, dass potenziell vorhandene Sicherheitslücken dadurch nicht geschlossen werden Informationen in der URL und in Formularen Viele Webanwendungen geben noch immer sehr viele Informationen in der URL preis. Durch verschiedene Parameter kann ein Angreifer oft erkennen, um welches System es sich handelt. Als Ende der 1990er Jahre durch die immer besser werdende PHP-Unterstützung zahlreiche Content-Management-Systeme aufkamen, setzte sich das Prinzip durch, viele Informationen durch Parameter über die URL zu übergeben. Diese URL s enthielten oft Benutzer-ID s und andere sicherheitsrelevante Informationen. Ein Angreifer konnte innerhalb von Sekunden erkennen, um welches System es sich handelte. Selbst recht unerfahrene Benutzer konnten durch Verändern von Werten die Anwendung kompromittieren. Viele Webanwendungen setzen aktuell auch noch auf das Prinzip. Grundsätzlich ist gegen die Informationsübermittlung durch die URL nichts einzuwenden. Sobald aber exotische Konstrukte oder sicherheitsrelevante Informationen (wie z.b. die Benutzer-ID) übermittelt werden, sollte von diesem Prinzip Abstand genommen werden. Der Apache Webserver erlaubt mittels htaccess die Übergabe einer URL, die so auf dem Server gar nicht existiert. Mittels dieser Direktive kann eine sehr kryptische URL in eine leserliche URL umgeschrieben werden. Die URL &searchstring=test&user_id=1 wird zu Intern wandelt der Apache-Webserver die kurze URL wieder in die lange URL

66 57 um, damit die Webanwendung sie verarbeiten kann. Der Benutzer bekommt davon nichts mit, der Browser zeigt nur die kurze URL an. Ein Angreifer hat es bei der kurzen URL wesentlich schwerer, das zugrunde liegende System zu erkennen. Das beschriebene Prinzip gilt nicht nur für URL s alleine, sondern auch für die Übergabe durch Formulare. Auch hier sollten keine sicherheitsrelevanten Informationen, wie die Benutzer-ID, übermittelt werden, da diese von einem Angreifer leicht manipuliert werden können und auf die Funktionsweise des Systems schließen lassen Kommentare, Metadaten und Dateialtlasten HTML-Kommentare und Meta-Daten verraten oft mehr über das eingesetzte System, als vielen Nutzern bewusst sind. Oft werden seitens der Programmierer Kommentare im HTML-Quelltext vergessen, die wichtige Informationen enthalten. In seltenen Fällen werden sogar komplette Logindaten im Quelltext vergessen. Auch Meta-Daten können einem Angreifer Aufschluss über das genaue System geben. Viele Anwendungen verwenden den Meta-Tag generator als Identifikationsmerkmal. Dort finden sich oft Name und Version des eingesetzten Systems. Ist ein Angreifer erst einmal an diese Informationen gelangt, kann er nach Altlasten oder Installationsroutinen suchen. Testdateien sind oftmals weniger gut gegen Angriffe gesichert oder geben den ungeschützten Zugriff auf interne Informationen frei, so dass ein Angreifer ohne große Umwege die Anwendung unter seine Kontrolle bringen kann. Um dies zu vermeiden, sollten sämtliche Kommentare und Meta-Daten, die auf das eingesetzte System schließen lassen, entfernt werden. Nicht benötigte Dateien sollten ebenfalls gelöscht werden, um einem Angreifer dort keinen Ansatzpunkt zu bieten Login Logins geben oftmals mehr Informationen an die Benutzer weiter als unbedingt nötig. Schlägt ein Loginversuch fehl, bekommt der Benutzer sehr oft die Information, woran der Login gescheitert ist. Gibt die Anwendung z.b. die Meldung aus, dass der angegebene Benutzername nicht gefunden wurde, kann ein Angreifer so lange einen Loginversuch unternehmen, bis diese Meldung nicht mehr auftritt. Danach kann er per Brute-Force das Passwort suchen. Da viele Benutzer noch immer einfache und kurze Passwörter verwenden, ist die Wahrscheinlichkeit groß, dass ein Angreifer in relativ kurzer Zeit das Passwort gefunden hat. Ein automatisiertes Script kann mehrere tausend Loginversuche pro Minute durchführen. Ein solcher Angriff zeigt nach wenigen Stunden, spätestens Tagen erste

67 58 Erfolge, je nach Benutzerstamm der Anwendung. Aus dem Grund sollte dem Benutzer nach einem fehlgeschlagenen Loginversuch zwar eine Meldung ausgegeben werden, jedoch nur mit der Information, dass seine Daten falsch sind. Ein legitimer Benutzer wird daraufhin seinen Anmeldenamen und sein Passwort überprüfen. Ein Angreifer kann nicht mehr Benutzernamen und Passwort durch Hilfe der Anwendung erraten Authentifizierung Der Login und die anschließende Authentifizierung des Benutzers ist einer der sensibelsten Bereiche einer Webanwendung. Um einen sicheren Ablauf zu gewährleisten, müssen einige Aspekte beachtet werden, die im Folgenden betrachtet werden SSL Ein jeder Login auf der Webanwendung sollte ausschließlich über eine verschlüsselte SSL-/TLS-Verbindung 37 erfolgen. Eine SSL-Verbindung stellt sicher, dass die Kommunikation zwischen dem Browser des Benutzers und der Anwendung verschlüsselt erfolgt. Durch ein Zertifikat wird zusätzlich sichergestellt, dass die Anwendung ihre Identität nachweist. Dazu können bei verschiedenen Anbietern im Internet Zertifikate erworben werden 38. Der Administrator eines Servers kann auch sein eigenes Zertifikat erstellen, um so Kosten zu sparen. Die Kommunikation ist anschließend zwar verschlüsselt, allerdings fehlt der Identitätsnachweis und der Browser zeigt eine spezielle Meldung an. Per SSL sollte nicht nur der Loginbereich, sondern ebenfalls alle anderen sensiblen Seiten der Anwendung abgesichert werden Benutzernamen Bei vielen Webanwendungen kann sich der jeweilige Benutzer mit seiner - Adresse anmelden. Ist diese Adresse einem Angreifer bekannt, muss dieser nur noch das zugehörige Passwort ermitteln. Da im Internet Listen kursieren, auf denen mehrere Millionen -Adressen aufgelistet sind, ist es für einen Angreifer kein Problem, an eine Vielzahl von Adressen zu gelangen. Aus diesem Grund sollte die Webanwendung dem Benutzer einen eindeutigen Anmeldenamen zuteilen, oder der Benutzer sollte diesen zumindest selber wählen können. Bei einem Login sollte ausschließlich dieser Anmeldename verwendet werden. 37 Secure Sockets Layer, [TLS 2009] 38 vgl. [OPENSSL 2009], [VERISIGN 2009]

68 Passwortstärke Die Passwörter der Benutzer stellen eine weitere Schwachstelle der Anwendung dar. Wählt der Benutzer ein zu kurzes Passwort, kann ein automatisiertes Script das Passwort innerhalb von Minuten erraten. Bei der Registrierung und im internen Bereich bei einer Passwortänderung sollte das Passwort im Optimalfall automatisch vergeben werden. Ist dies aus Gründen des Benutzerkomforts nicht gewünscht, sollte das Passwort zumindest auf einige Sicherheitsaspekte geprüft werden. Damit ein Passwort einer Brute-Force Attacke einige Zeit lang standhält, sollte es aus mindestens 8 Zeichen bestehen. Ebenfalls sollten Groß- und Kleinschreibung sowie Sonderzeichen verwendet werden. PECL 39 stellt die Erweiterung ext/crack zur Verfügung, mit der Passwörter auf ihre Stärke geprüft werden können. Ist das Passwort zu schwach, werden verschiedene Meldungen ausgegeben. So kann sichergestellt werden, dass der Benutzer ein sicheres Passwort verwendet Stammdatenprüfung Nachdem der Benutzer über Loginformular übermittelt hat (hier sollte als Request- Methode nur POST verwendet werden), müssen die Daten mit den gespeicherten Informationen in der Datenbank abgeglichen werden. Da Benutzernamen und Passwörter innerhalb der Datenbank meist in VARCHAR-Feldern gespeichert werden, unterscheidet die Datenbank nicht zwischen Groß- und Kleinschreibung. Ein Benutzer, dessen Anmeldename sich nur durch Groß-/ Kleinschreibung von einem anderen Benutzer unterscheidet, erhält möglicherweise daraufhin die Rechte des anderen Benutzers. Um diese Problematik zu vermeiden, sollte der übermittelte Anmeldename gehasht werden und dieser mit dem gehashten Wert des gespeicherten Anmeldenamens verglichen werden. Alternativ kann der Anmeldename auch ungehasht vergleichen werden, bei MySQL kann dafür das Schlüsselwort BINARY verwendet werden. Hier werden dann auch Groß- und Kleinschreibung beachtet Sichere Passwortverwaltung Passwörter sollten niemals im Klartext in der Datenbank abgelegt werden. Würde einem Angreifer Zugriff auf die Datenbank gelingen, lägen ihm sämtliche Passwörter der registrierten Benutzer als Klartext vor. Aus diesem Grund sollten Passwörter immer gehasht oder zumindest verschlüsselt in der Datenbank gespei- 39 vgl. [PECL 2008]

69 60 chert werden. Hierbei ist Hashing einer Verschlüsselung vorzuziehen, da ein Hash-Wert nicht in seinen Ursprungswert entschlüsselt werden kann Salting Da der weit verbreitete Hash-Algorithmus MD5 durch zahlreiche Rainbow-Tables angreifbar geworden ist, sollten Passwörter mit einem noch sichereren Algorithmus gehasht werden. Allerdings ist es auch bei neuen Algorithmen nur eine Frage der Zeit, bis Rainbow-Tables eine beachtliche Größe annehmen werden. Dies stellt auch keine Sicherheitslücke im Algorithmus selbst dar, sondern liegt in der Natur der Sache einer Prüfsumme. Je länger ein Algorithmus eingesetzt wird, desto größer werden die Rainbow-Tables. Gelangt ein Angreifer an das gehashte Passwort, z.b. durch Session-Diebstahl, kann er den Hash mit einer Rainbow- Table abgleichen. Sind die Passwörter recht kurz und enthalten wenig oder keine Sonderzeichen, ist die Wahrscheinlichkeit groß, dass ein Klartextwert ausgelesen werden kann. Um diesem Problem zu begegnen, kann das so genannte Salting 40 eingesetzt werden. Bei dieser Methode wird vor dem eigentlichen Hashing-Vorgang ein zusätzlicher Wert an das zu hashende Passwort angehängt. Dies kann z.b. ein kompletter 32-Bit Hash sein. Danach wird die neu entstandene Zeichenkette gehasht. $passwort = meinpasswort ; // Hash-Wert: f14a298bc87fff2cd757f71054fdd94d $salt = meinsalt ; // Hash-Wert: b056ca9af325f c115d8a511b $passwort_hashed = md5(md5($passwort).md5($salt)); // Hash-Wert: 4d603d1c02d2562c13b7f8f364a3b9a6 In diesem Beispiel wird das eigentliche Passwort meinpasswort in einen md5- Hash umgerechnet. An den entstandenen Hash wird ein zweiter Hash, das so genannte salt angehängt. Die neue Zeichenkette 41 wird erneut gehasht. Dieser Wert wird anschließend in der Datenbank abgelegt. Gelangt nun ein Angreifer an diesen Wert, kann er zwar unter Umständen eine passende Zeichenkette finden, diese stellt aber nicht das Passwort des Benutzers dar und ist somit für den Angreifer nutzlos. Selbst wenn ein Angreifer den Salt und die Salting-Methode 40 vgl. [HEIDERICH et. al 2009, S. 407] 41 zwei 32-Stellige Hash-Werte kombiniert

70 61 kennt, benötigt er viel Zeit, um das ursprüngliche Passwort per Brute-Force zu errechnen. Bei einem 8-Stelligen Passwort, das Buchstaben 42 und Zahlen besteht, benötigt ein Angreifer über 15 Tage, bis er sämtliche Kombinationen errechnet hat. Bei neun Stellen sind es schon über 2,5 Jahre Vergessene Passwörter Die Salting-Methode bringt durch ihre Sicherheit für den Benutzer eine kleine Unbequemlichkeit mit sich. Sollte er sein Passwort vergessen, kann es ihm nicht wieder angezeigt werden. Viele Anwendungen senden dem Benutzer das Passwort (oder auch ein neu generiertes Passwort) per Mail zu, rein aus Gründen der Bequemlichkeit. Da die meisten Mails noch immer unverschlüsselt versendet und ebenfalls unverschlüsselt empfangen werden, sollten Passwörter nie per Mail an einen Benutzer geschickt werden. Für den Fall, dass ein Benutzer sein Passwort vergessen hat, sollte die Webanwendung ein neues Passwort generieren und dem Benutzer dieses als Klartext einmalig anzeigen. Alternativ kann auch ein Captcha für die Anzeige verwendet werden Sessions Da HTTP ein zustandsloses Protokoll ist, kann der Server den Client ohne Hilfsmittel nicht eindeutig identifizieren. Aus diesem Grund wurden Sessions eingeführt, mit deren Hilfe eine eindeutige Zuordnung des Clients möglich ist. Da Sessions von PHP verwaltet werden, ist die Benutzung sehr einfach, sie eignen sich deshalb sehr gut für Logins Einstellungen Auch bei Sessions müssen einige Sicherheitsaspekte beachtet werden. Die Session- ID sollte aus Sicherheitsgründen nur in einem Cookie gespeichert werden und sollte nicht per POST oder GET übergeben werden. Als zusätzliche Absicherung sollte die Option http-only 44 aktiviert werden. Sie verhindert, dass der Session- Cookie per JavaScript ausgelesen wird und ein Sessiondiebstahl stattfindet. Das Starten einer Session muss vom Server ausgehen. Übermittelt ein Benutzer eine eigene Session-ID, muss diese durch eine neue ID ersetzt werden, damit 42 inkl. Groß-/ Kleinschreibung 43 bei ca. 167 Millionen errechneten Werten pro Sekunde 44 vgl. [PHP 2009(9)]

71 62 ein Angreifer einem potenziellen Opfer keine manipulierte Session-ID unterschieben kann. Nach einem Logout sollte die komplette Session beendet werden, damit im http-header keine Spuren der vorherigen Session zurückbleiben, falls die Session-ID doch per URL übergeben wurde. PHP bietet zudem die Möglichkeit, den Speicherort der Sessiondaten auf dem Server zu ändern. In der Standardeinstellung werden diese Daten in einem temporären Ordner abgelegt. Sind die Zugriffsrechte unzureichend gesetzt, könnte ein fremdes Script die Sessiondaten auslesen. Aus diesem Grund sollte der Speicherort einer Session in einen anderen Ordner verlegt werden. Die Daten können ebenfalls in der Datenbank gespeichert werden. Je nach Anzahl der Benutzer kann dies jedoch zu einer erhöhten Last auf dem Server führen Sessionnutzung zur Authentifizierung Sessions eignen sich hervorragend zur Authentifizierung von Benutzern. Nach einem erfolgreichen Login können Benutzerrechte und weitere Optionen in der Session gespeichert werden. So muss nicht bei jedem Seitenaufruf eine Datenbankanfrage stattfinden, um diese Informationen auszulesen. Zudem ist die Benutzung von Sessions im Vergleich zur manuellen Cookieverwaltung sicherer, ein Angreifer hat bei Sessions keine Möglichkeit vorgegebene Werte zu manipulieren (bis auf die Session-ID selbst). Aus diesem Grund können in Sessions Informationen gespeichert werden, die normalerweise nicht in Cookies platziert werden sollten Automatisiertes Aufbereiten von Eingaben Wie die große Zahl an Sicherheitslücken in Webanwendungen zeigt, sind sich viele Programmierer nicht im Klaren, wie gefährlich vom Benutzer übergebene Werte sein können. Sicherungsmaßnahmen werden aus Unwissenheit oder Unachtsamkeit nicht implementiert, so dass die Webanwendung einem Angreifer schutzlos ausgeliefert ist. Da dies auch bei sehr großen und bekannten Webanwendungen der Fall ist, könnte ein automatisiertes Aufbereiten von Benutzereingaben Abhilfe schaffen und die meisten Sicherheitslücken schließen Funktionsweise Benutzer können über verschiedene Wege Informationen an die Webanwendung übermitteln. Hier spielen nicht nur POST und GET eine Rolle, sondern eine Vielzahl von anderen Möglichkeiten: $_SERVER

72 63 $_POST $_GET $_REQUEST $_COOKIE $_FILES Über diese Variablen hat ein Script Zugriff auf Werte, die vom Benutzer vorgegeben werden. Wenn überhaupt eine Prüfung stattfindet, beschränkt diese sich meistens auf POST und GET. Dabei wird übersehen, dass selbst $_SERVER potenziell gefährliche Werte enthalten kann, die ein Angreifer einschleusen möchte. Viele Anwendungen übernehmen Headerdaten für Statistiken. Da diese Daten vermeintlich nicht vom Benutzer, sondern vom Browser stammen, werden diese oft ungeprüft in ein SQL-Statement übernommen. Ein Angreifer kann z.b. den Host oder Referer manipulieren und so Injections einschleusen. Bevor diese Werte vom Script zur Weiterverarbeitung übernommen werden, tritt die automatisierte Aufbereitung in Aktion. Sie dekodiert die Werte, entfernt HTML sowie Scripting und nimmt ein Escaping der Werte vor. Dies kann über eine spezielles Script erreicht werden, das am Anfang der zu schützenden Datei per include eingebunden wird. Anschließend kann der Programmierer im Script die Variablen verwenden, ohne eine weitere Prüfung auf XSS oder Injections vornehmen zu müssen. Lediglich die Prüfung des Varablentyps obliegt dem Programmierer selbst, da die vorherige Prüfung natürlich nicht wissen kann, welchen Typ der Programmierer erwartet. Durch eine solche automatisierte Aufbereitung können durch Flüchtigkeitsfehler keine Sicherheitslücken mehr entstehen. Ein weiterer Vorteil der automatisierten Aufbereitung liegt in der einfachen Pflege. Werden neue Angriffsmuster bekannt die bislang nicht erkannt wurden, ist nur eine Datei zu tauschen. Vorher mussten sämtliche Scripte der Anwendung überprüft und geändert werden Risiken Die automatisierte Aufbereitung stellt zwar eine praktische Methode dar um Sicherheitslücken zu schließen, aber auch hier müssen einige Punkte beachtet werden. Am Anfang einer jeden Datei muss die entsprechende Routine eingefügt werden. Dies ist zwar durch eine einzige include-zeile möglich, jedoch darf auch hier die Unachtsamkeit vieler Programmierer nicht unterschätzt werden.

73 64 Werden nach der Aufbereitung Werte vom Programmierer verändert, z.b. durch das Kürzen des Strings oder durch das Ersetzen von Zeichen, können nicht vorhersehbare Effekte auftreten. Nach einer solchen Aktion muss der Benutzer die Variable erneut aufbereiten lassen. Die Routine kann dafür eine spezielle Funktion zur Verfügung stellen. Auch hier muss der Programmierer diese Aktion bewusst vornehmen, um eventuelle Risiken zu vermeiden. Jedoch ist hier die Gefahr einer Sicherheitslücke niedrig, da die Wahrscheinlichkeit gering ist, dass durch eine Bearbeitung ein neuer gefährlicher String entsteht. Die Möglichkeit besteht jedoch und sollte deshalb auch nicht unerwähnt bleiben.

74 65 5 Evaluation von drei Content-Management-Systemen Content-Management-Systeme (CMS) erfreuen sich seit einiger Zeit großer Beliebtheit. Über ein CMS kann ein Autor ohne Kenntnis von HTML oder Programmiererfahrung unter anderem eine umfangreiche Homepage erstellen. Wird das CMS ausschließlich im Web-Bereich eingesetzt, vorwiegend zur Verwaltung von Webseiten, wird auch von WCMS (Web-Content-Management-System) gesprochen. In diesem Kapitel werden drei prominente Systeme betrachtet: Typo3 1 Joomla 2 Drupal 3 Anhand der in Kapitel 4 erarbeiteten Sicherungen werden diese drei Systeme geprüft. 5.1 Grundlagen Die hier zu betrachtenden Systeme sind als Open-Source Software frei zum Download erhältlich, basieren auf PHP und benötigen eine MySQL Datenbank. Über ein Administrator-Backend können sämtliche notwendigen Einstellungen vorgenommen werden. Die Änderungen werden sofort übernommen, der Benutzer muss keinerlei Dateien hochladen, wie es bei einer Offline-Änderung der Fall wäre. Durch verschiedene Module, die entweder direkt vom Anbieter aber auch von Dritten zum Download angeboten werden, können alle drei Systeme um verschiedene Funktionen erweitert werden. 1 vgl. [TYPO3 2009] 2 vgl. [JOOMLA 2009] 3 vgl. [DRUPAL 2009]

75 Prüfschema Alle drei Systeme werden anhand eines festen Prüfschemas auf Sicherheitslücken getestet. Dabei werden Tests über Beispielseiten durchgeführt, die in jedem System zum Testen erstellt wurden. Ebenso werden die wichtigsten Dateien auf Risiken im Code selbst geprüft. Funktionalität, Bedienbarkeit und andere qualitative Aspekte werden ausdrücklich nicht betrachtet. Da sich alle Systeme hinsichtlich ihres Einsatzes und Umfangs unterscheiden, muss der Anwender für sich selber entscheiden, welches System seinen Ansprüchen genügt. Die durchgeführten Prüfungen dienen ausschließlich zur Feststellung der Sicherheit und inwieweit Risiken in der Software bestehen Server Alle drei Content-Management-Systeme werden sowohl auf einem virtuellem Windows- und Linux-Server getestet. Der Windows-Server wird mit Windows XP betrieben. Als Webserver kommt Apache 2 zum Einsatz. MySQL 5 dient als Datenbankserver. PHP liegt in der Version vor. Die Fehlerberichte von PHP sind aktiviert, damit z.b. eine SQL-Injection leicht erkannt werden kann. Auch lässt sich so überprüfen, ob das System sauber programmiert wurde, oder ob schon im normalen Betrieb Fehlermeldungen von PHP ausgegeben werden Tests Im Folgenden werden verschiedene Tests vorgestellt, die bei allen Systemen angewendet werden. Bei allen Systemen werden sowohl der Softwarekern, als auch Erweiterungen getestet. Weist schon der Kern Sicherheitslücken auf, ist es für einen Angreifer ein Leichtes die Software zu kompromittieren oder sie komplett zu übernehmen. Erweiterungen stellen ebenfalls ein großes Risiko für die Systemintegrität dar. Viele populäre Erweiterungen stammen von Drittentwicklern, die oftmals sicherheitsrelevante Prüfungen vernachlässigen und Angreifern so ein Einfallstor in die Software bieten SQL-Injections Da alle Systeme Informationen vom Benutzer entgegennehmen, werden verschiedene Zeichenketten eingegeben um die Behandlung von SQL-Injections zu überprüfen. Geprüft werden Informationen aus verschiedenen Quellen:

76 67 GET POST COOKIE HEADER Folgende Zeichenkombinationen werden getestet: einfaches Anführungszeichen: doppeltes Anführungszeichen: " Apostroph 1: Apostroph 2: Werden Zeichen nicht escaped, wird eine Fehlermeldung ausgegeben. Dann besteht die Gefahr einer SQL-Injection. Zusätzlich werden die Zeichen dezimalund hexadezimal codiert. Nimmt ein System z.b. eine Dekodierung nach dem Escapen vor, besteht ebenfalls die Gefahr einer Injection. Ebenfalls werden relevante PHP-Dateien in einem Editor per Hand auf Gefahren untersucht Header-Injections Alle drei Systeme versenden nach gewissen Benutzeraktionen s (z.b. nach Absenden eines Kontaktformulars). Werden die Benutzereingaben nicht überprüft, besteht die Gefahr einer Header-Injection. Deshalb werden über die jeweiligen Kontaktformulare Zeichen übermittelt, die eine Header-Injections auslösen können: \n \r Diese Zeichen können in Kombination mit anderen Konstrukten Header-Injections auslösen NULL-Byte-Injections Für den Fall, dass ein geprüftes System dynamische includes() vornimmt, die vom Benutzer übergebene Werte in den Dateinamen übernehmen, wird das System auf NULL-Byte-Injections geprüft.

77 Cross-Site Scripting Da XSS eine der gefährlichsten Sicherheitslücken in Webanwendungen darstellt, wird jedes System mehrfach auf verschiedene Arten von XSS geprüft. Um die Sicherheit und eventuell vorhandene Filter zu testen, werden verschiedene XSS- Konstrukte getestet. Diese werden unter anderem auch Dezimal- und Hexadezimal kodiert. Insgesamt werden 15 verschiedene XSS-Konstrukte getestet, die je nach Filter und Browser unterschiedliche Ergebnisse hervorbringen. XSS Test 1: <script>alert( XSS! )</script> XSS Test 2: <IMG SRC="javascript:alert( XSS );"> XSS Test 3: <IMG """><SCRIPT>alert("XSS")</SCRIPT>"> XSS Test 4: <IMG SRC=javascri pt:alert( &#39;XSS&#39;)> XSS Test 5: <IMG SRC=&# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# &# > XSS Test 6: <IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70 &#x74&#x3a&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x58&#x53 &#x53&#x27&#x29> XSS Test 7: <SCRIPT/XSS SRC=" XSS Test 8: <BODY =alert("xss")>

78 69 XSS Test 9: <<SCRIPT>alert("XSS");//<</SCRIPT> XSS Test 10: <IMG SRC="javascript:alert( XSS )" XSS Test 11: </TITLE><SCRIPT>alert("XSS");</SCRIPT> XSS Test 12: <BODY ONLOAD=alert( XSS )> XSS Test 13: <STYLE>BODY{-moz-binding:url(" xssmoz.xml#xss")}</style> XSS Test 14: <STYLE>li {list-style-image: url("javascript: alert( XSS )");}</STYLE><UL><LI>XSS XSS Test 15: ;alert(string.fromcharcode(88,83,83))//\ ; alert(string.fromcharcode(88,83,83))//"; alert(string.fromcharcode(88,83,83))//\"; alert(string.fromcharcode(88,83,83))//--></script>"> > <SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT> Die Tests wurden aus dem XSS Cheat Sheet 4 übernommen Cross-Site Request Forgery Ob ein System gegen CSRF geschützt ist, lässt sich sehr einfach erkennen. Meist wird an die URL ein Token mit einem Hash-Wert angehängt. In Formularen findet sich dieser Token oft in versteckten Feldern. Fehlt dieser Token, ist das System nicht gegen CSRF geschützt. Da sich die einzelnen Systeme funktional voneinander unterscheiden, können nur individuelle Tests vorgenommen werden. Folgende Bereiche werden mit den 4 vgl. [RSNAKE 2009]

79 70 Tests abgedeckt: forcierter Logout gefälschte URL- und Formularübergaben Um die Tests durchzuführen wird eine Testwebseite angelegt. Nur durch das Betreten dieser Seite werden anschließend Requests im Namen des eingeloggten Benutzers ausgeführt. Es ist keine Aktion des Benutzers nötig. 5.3 Typo3 Von den hier getesteten Content-Management-Systemen stellt Typo3 das umfangreichste System dar. Konzipiert ist Typo3 für mittlere bis große Webseiten. Typo3 wurde 1998 von Kasper Skårhøj entwickelt und veröffentlicht 5 und steht unter GNU GPL-Lizenz 6. Mittlerweile wird Typo3 von einer größeren Gemeinschaft weiterentwickelt. Es existieren zahlreiche Module, mit denen die Funktionen von Typo3 erweitert werden können. Diese Module werden sowohl offiziell von Typo3 herausgegeben als auch von Dritten Konfiguration Typo3 liegt in der Version mit dem neuesten Update vor. Als Extensions kommen Static Info Tables 7, TemplaVoila! 8 und Modern Guestbook / Commenting system 9 zum Einsatz Softwarekern Der Softwarekern von Typo3 stellt die Grundlegenden Funktionen von Typo3 bereit. Dazu gehören unter anderem das Aufrufen von den jeweils angelegten Seiten, ein Login für den Frontend-Benutzer, aber auch eine Suche, mit deren Hilfe ein Benutzer Informationen schnell finden kann. Um den Softwarekern von Typo3 zu testen, werden diese drei Funktionen getestet, da sie in jeder Typo3 Installation enthalten sind und so immer ein Risiko darstellen, falls in einer dieser Funktionen eine Sicherheitslücke enthalten ist. 5 vgl. [TYPO3 2008] 6 vgl. [GNU 2009] 7 vgl. [FRITZ 2008] 8 vgl. [DULEPOV 2008] 9 vgl. [VON EYNERN 2008]

80 SQL-Injections Die in beschriebenen Tests werden wie dort angegeben durchgeführt. Die nachfolgende Tabelle zeigt die Ergebnisse der verschiedenen Tests. Abbildung 5.1: Typo3-Kern SQL-Injection Testresultat Wie der Test zeigt, ist der Softwarekern von Typo3 in der aktuellen Version gegen SQL-Injections abgesichert. Als sicherndes Element kommt unter anderem die Datei class.t3lib_db.php 10 zum Einsatz. Sie stellt die Funktion quotestr zur Verfügung, die dazu verwendet werden muss, Zeichenketten zu escapen, bevor diese in einer Datenbankabfrage verwendet werden. Die Funktion wird unter anderem in der Datei class.tslib_content.php 11 verwendet, die für Teile der Hauptfunktionen genutzt wird. Die Funktion wird ebenfalls in der Suche verwendet Header-Injections Typo3 versendet unter anderem über Kontaktformulare s an Benutzer, Redakteure und Administratoren. Um diese Funktion zu testen, werden wie in beschrieben, verschiedene Sonderzeichen in ein Kontakt-Formular eingegeben. Abbildung 5.2: Typo3-Kern Header-Injection Testresultat 10 Pfad: typo3/t3lib/class.t3lib_db.php, Zeile 606ff 11 Pfad: typo3/t3lib/ class.tslib_content.php, Zeile 6697ff 12 Pfad: typo3/t3lib/class.tslib_search.php, Zeile 388

81 72 Der Test hat gezeigt, dass Typo3 gegen Mail-Header-Injections gesichert ist und so ein Angreifer den Typo3-Kern nicht für den Versand von Spam nutzen kann NULL-Byte-Injections Da die getesteten Typo3-Funktionen keine dynamischen include()-anweisungen mit Benutzerwerten durchführen, muss dieser Test nicht durchgeführt werden.

82 Cross-Site Scripting Der Cross-Site Scripting Test wird einmal im Suchfeld und einmal für den Login durchgeführt, da Typo3 so konfiguriert wurde, dass der Suchbegriff dem Benutzer in der Ergebnisliste noch einmal angezeigt wird. Bei einem fehlerhaften Login wird ebenfalls der Benutzername im Loginfeld erneut angezeigt. Abbildung 5.3: Typo3-Kern XSS Testergebnis Der Typo3 Kern war gegen kein XSS-Konstrukt des Tests anfällig. Sämtliche potenziell gefährliche Zeichen werden in ihre jeweilige HTML-Entität umgewandelt.

83 Cross-Site Request Forgery Um die CSRF-Tests durchführen zu können, wurde speziell für die Typo3-Installation eine Webseite erstellt, von der die falschen Requests im Namen eines angemeldeten Benutzers durchgeführt werden. Nur durch das Betreten dieser Webseite, führt der Benutzer eine Aktion aus, ohne davon zu wissen. Abbildung 5.4: Typo3-Kern Header-Injection Testresultat Da die vorliegende Testversion von Typo3 für keine weiteren Benutzeraktionen konfiguriert wurde, die für CSRF-Angriffe verwendet werden können, musste sich der Test auf die o.g. zwei Aktionen beschränken (im Kapitel wird allerdings noch ein CSRF-Angriff auf eine Extension durchgeführt). Diese Aktionen waren allerdings beide erfolgreich. Durch das Fehlen eines Tokens in der URL und in einem versteckten Feld des Formulars werden die Angriffe ermöglicht Extensions Für Typo3 existieren mehrere Hundert Extensions, die entweder direkt von Typo3 aber auch von Dritten erhältlich sind. Alle Extensions zu testen, würde den Rahmen dieser Ausarbeitung sprengen. Aus diesem Grund wurde die sehr populäre Extension ve_guestbook 13 für den Test ausgewählt, die schon über hunderttausend Mal von der Typo3 Seite heruntergeladen wurde SQL-Injections Wie auch bei dem Test des Typo3-Kerns werden verschiedene Sonderzeichen Abbildung 5.5: Typo3-Extension SQL-Injection Testresultat 13 Version 2.7.1

84 75 Das ve_guestbook -Formular enthält verschiedene Felder, die ein Benutzer ausfüllen muss, um einen Kommentar auf der Webseite zu hinterlassen. Alle diese Felder wurden mit den in beschriebenen Sonderzeichen versehen. Es erfolgte keine SQL-Injection Header-Injections Da ve_guestbook keine s an Benutzer versendet, muss dieser Test nicht durchgeführt werden NULL-Byte-Injections ve_guestbook nutzt keine include()-anweisung mit Werten die vom Benutzer übergeben wurden, deshalb muss auch dieser Test nicht durchgeführt werden.

85 Cross-Site Scripting Um zu testen, ob ve_guestbook hinreichend gegen XSS geschützt ist, werden die in beschriebenen Konstrukte in die sämtliche Felder des Formulars eingegeben. Abbildung 5.6: Typo3-Extension XSS Testresultat Bei diesem Test konnte keine XSS-Attacke erfolgreich ausgeführt werden. In ve_guestbook ist eine Whitelist enthalten, die nur vom Administrator erlaubte HTML-Tags zulässt.

86 Cross-Site Request Forgery Schon auf den ersten Blick ist zu sehen, dass ve_guestbook gegen CSRF- Angriffe geschützt ist. Um einen Kommentar abzusetzen, muss der Benutzer vorher ein CAPTCHA ausfüllen. Da sich dieses CAPTCHA bei jedem Seitenaufruf verändert, hat ein Angreifer keine Möglichkeit, einen Request im Namen des Benutzers abzusetzen. Die CAPTCHA Funktion ist allerdings nicht zwingend erforderlich, ve_guestbook kann auch ohne diese Funktion betrieben werden. Dann besteht allerdings wie bei anderen Formularen auch, die Gefahr von CSRF- Attacken auf die Extension. Die CAPTCHA-Funktion sollte deshalb in jeden Fall aktiviert werden Administrations-Backend Das Administrations-Backend von Typo3 erlaubt dem Administrator die komplette Kontrolle über die Software. Ein Angreifer hat keinen direkten Zugriff auf das Backend, könnte aber die Loginfelder für eine SQL-Injection nutzen, falls diese unzureichend gesichert sind. Ein Angreifer kennt ebenfalls die Struktur des Backend, da dieses bei jeder Typo3-Installation, bis auf verschiedene Extensions, gleich ist. Deshalb wird das Backend auf SQL-Injections und CSRF getestet SQL-Injections Um das Loginformular auf SQL-Injections zu testen, wurden die in beschriebenen Sonderzeichen eingegeben. Abbildung 5.7: Typo3-Backend SQL-Injection Testresultat Wie der Test zeigt, ist der Login des Backends gegen SQL-Injections gesichert.

87 Cross-Site Request Forgery Abbildung 5.8: Typo3-Backend CSRF Testresultat Wie schon im Frontend konnte der angemeldete Administrator ohne Probleme aus dem Administrations-Backend ausgeloggt werden. Das Anlegen eines neuen Benutzers war jedoch nicht erfolgreich.

88 Sicherheitslücken in der Vergangenheit Typo3 hat in der Vergangenheit zahlreiche Sicherheitslücken gezeigt. Sehr viele Risiken sind auf fehlerhaft programmierte Extensions zurückzuführen. SQL- Injections und XSS sind dort am meisten vertreten. Doch auch der bislang als sicher geglaubte Softwarekern von Typo3 hat vor kurzer Zeit eine schwere Sicherheitslücke gezeigt 14. Über Teile der Suchfunktion konnten SQL-Injections ausgeführt werden, so dass der Angreifer die volle Kontrolle über die Software erlangen konnte. Da Updates zeitlich oft Angriffen hinterherhängen, wurden zahlreiche Webseiten Opfer des Angriffs, darunter auch recht prominente. So wurde beispielsweise die Webseite von Bundesinnenminister Dr. Wolfgang Schäuble von Angreifern verändert 15. Abbildung 5.9: Veränderte Webseite von Bundesinnenminister Dr. Wolfgang Schäuble vgl. [TYPO3 2009(2)] 15 vgl. [SCHMIDT 2009] 16 vgl. [HEISE 2009]