Archiv der Kategorie: Security

Hashverfahren und Sicherheit

Es gehört mittlerweile zum guten Ton, auf md5 herumzuhacken. Dabei fällt immer wieder das Argument, dass in md5 Kollisionen entdeckt wurden. Eine Kollision bedeutet, dass zwei unterschiedliche Strings zum gleichen Hash führen. Dies muss zwangsläufig bei allen Hashverfahren der Fall sein, denn eine Abbildung von viel Text auf wenig Text wird naturgemäß irgendwann eine Überschneidung bei zwei verschiedenen Inputs ergeben. Ein gutes Hashverfahren kommt also mit weniger Kollisionen daher als ein schlechtes.

Zum selbst testen (Unterschiede im Input sind mit einem Ausrufezeichen vermerkt):

$a = md5("\xA6\x64\xEA\xB8\x89\x04\xC2\xAC\x48\x43\x41\x0E\x0A\x63\x42\x54\x16\x60\x6C\x81\x44\x2D\xD6\x8D\x40\x04\x58\x3E\xB8\xFB\x7F\x89\x55\xAD\x34\x06\x09\xF4\xB3\x02\x83\xE4\x88\x83\x25\x71\x41\x5A\x08\x51\x25\xE8\xF7\xCD\xC9\x9F\xD9\x1D\xBD\xF2\x80\x37\x3C\x5B\x97\x9E\xBD\xB4\x0E\x2A\x6E\x17\xA6\x23\x57\x24\xD1\xDF\x41\xB4\x46\x73\xF9\x96\xF1\x62\x4A\xDD\x10\x29\x31\x67\xD0\x09\xB1\x8F\x75\xA7\x7F\x79\x30\xD9\x5C\xEB\x02\xE8\xAD\xBA\x7A\xC8\x55\x5C\xED\x74\xCA\xDD\x5F\xC9\x93\x6D\xB1\x9B\x4A\xD8\x35\xCC\x67\xE3");
$b = md5("\xA6\x64\xEA\xB8\x89\x04\xC2\xAC\x48\x43\x41\x0E\x0A\x63\x42\x54\x16\x60\x6C\x01\x44\x2D\xD6\x8D\x40\x04\x58\x3E\xB8\xFB\x7F\x89\x55\xAD\x34\x06\x09\xF4\xB3\x02\x83\xE4\x88\x83\x25\xF1\x41\x5A\x08\x51\x25\xE8\xF7\xCD\xC9\x9F\xD9\x1D\xBD\x72\x80\x37\x3C\x5B\x97\x9E\xBD\xB4\x0E\x2A\x6E\x17\xA6\x23\x57\x24\xD1\xDF\x41\xB4\x46\x73\xF9\x16\xF1\x62\x4A\xDD\x10\x29\x31\x67\xD0\x09\xB1\x8F\x75\xA7\x7F\x79\x30\xD9\x5C\xEB\x02\xE8\xAD\xBA\x7A\x48\x55\x5C\xED\x74\xCA\xDD\x5F\xC9\x93\x6D\xB1\x9B\x4A\x58\x35\xCC\x67\xE3");
//--------------------------------------------------------------------------------------!-------------------------------------------------------------------------------------------------------!-------------------------------------------------------!-----------------------------------------------------------------------------------------------!-------------------------------------------------------------------------------------------------------!-------------------------------------------------------!------------------

var_dump($a); //string(32) "2ba3be5aa541006b62370111282d19f5"
var_dump($b); //string(32) "2ba3be5aa541006b62370111282d19f5"
var_dump($a === $b); //bool(true)

Veröffentlicht unter php, Security, webdev | 18 Kommentare

Dealing with Trusted Timestamps in PHP (RFC 3161)

This article won’t be pariculary interesting for the most readers. My aim is to help the billions of developers that are confused about dealing with trusted timestamping. If you don’t know what Trusted Timestamps are, carry on.

Explanation of the concept behind Trusted Timestamps

I can’t put it better as Wikipedia (Trusted timestamping) does:

Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper’s integrity is never compromised.

Veröffentlicht unter php, Security, webdev | 13 Kommentare

Datenbank-Transaktionen von akademischer Seite: Behind the Scenes

Disclaimer

An diejenigen mit ordentlichen Vorkenntnissen auf dem Gebiet der Transaktionen: Bitte nicht Abschrecken lassen. Es geht nach der kurzgehaltenen Einführung noch ordentlich in die Tiefe.

Was sind Transaktionen

Nach Definition ist eine Transaktion eine logische Arbeitseinheit, die entweder ganz oder garnicht durchgeführt wird. Bei einem Fehler wird die Datenbank also in den Zustand vor Ausführung der Transaktion versetzt, als ob nie etwas geschehen wäre.

Beispiel: Wo könnte man Transaktionen mehr benötigen als auf einem Gebiet, auf dem Fehler richtig weh tun? Die Bankenwelt! Man stelle sich folgendes ultrasimples Datenmodell vor:

CREATE TABLE  `konto` (
`kontonr` INT NOT NULL PRIMARY KEY ,
`betrag` INT NOT NULL DEFAULT  '0',
`kundenid` INT NOT NULL
) ENGINE = INNODB;

CREATE TABLE  `ueberweisung` (
`ueberweisungsid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`from_kontonr` INT NOT NULL ,
`to_kontonr` INT NOT NULL ,
`betrag` INT NOT NULL
) ENGINE = INNODB;

Veröffentlicht unter php, Datenbanken, Security, webdev | 9 Kommentare

fieser Bug in PHP 5.3 [Update]

Man stelle sich folgenden Quellcode in einem Onlinebanking-Formular vor:

<?php
if (!empty($_POST['ueberweisungsbetrag']) && filter_var($_POST['ueberweisungsbetrag'], FILTER_VALIDATE_FLOAT)!==false)
{
    $ueberweisungsbetrag = $_POST['ueberweisungsbetrag'];
}
else
{
    $ueberweisungsbetrag = 0;
}
?>
<input type="text" name="ueberweisungsbetrag" value="<?php echo $ueberweisungsbetrag; ?>" />

Sieht ja eigentlich erstmal ganz vernünftig aus, oder? Validierung des einigegebenen $_POST-Betrags, um dem Benutzer bei einem Fehler das erneute eintippen zu ersparen. Wenn man nun allerdings die verdammt kleine Gleitkommazahl 2.2250738585072011e-308 als Betrag eintippt, hat das den gleichen Effekt wie

while (true) {}

Nämlich: Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/test.php on line 3. Diese ominöse Zahl führt also PHP-intern zu einem verrecken des Scripts. Das passiert immer, wenn die Zahl auch wirklich als Zahl interpretiert wird.

Heißt:

print $_GET['floatval']; // doc.php?floatval=2.2250738585072011e-308 -> no problem - treated as string
print "2.2250738585072011e-308"; // no problem - string
print 2.2250738585072011e-308; //crash!
print "2.2250738585072011e-308"*1; // crash!
print (float)"2.2250738585072011e-308"; // crash!
filter_var("2.2250738585072011e-308", FILTER_VALIDATE_FLOAT); // crash!

Veröffentlicht unter php, Security, webdev | 3 Kommentare

Richtige Stelle zum Encoden?

Ich war bisher immer ein Verfechter der „jeglichen Input sofort encoden“-Schiene. Heißt: Bevor ich Benutzereingaben in der Datenbank abspeichere / eine Bestätigungsemail versende etc. werden die Daten encodet (htmlentities oder ähnliches). Nun bin ich auf diesen sehr interessanten Artikel gestoßen (inspiriert durch einen Post zur ungarischen Notation beim phphacker), der folgende Position vertritt:

For example maybe you want to store these user strings in a database somewhere, and it doesn’t make sense to have them stored HTML-encoded in the database, because they might have to go somewhere that is not an HTML page, like to a credit card processing application that will get confused if they are HTML-encoded. Most web applications are developed under the principle that all strings internally are not encoded until the very last moment before they are sent to an HTML page, and that’s probably the right architecture.

Veröffentlicht unter Security, webdev, misc IT | 8 Kommentare

Kreative Attacken mit CSRF

Frei nach der Devise „know your enemy“ möchte ich in diesem Post etwas auf weniger offensichtliche Möglichkeiten eingehen, wie mit CSRF attackiert werden kann. CSRF selbst habe ich übrigens hier genauer erklärt.

1) Feststellen, ob ein Benutzer bestimmte Seiten besucht hat

Es gibt ja bereits seit längerem die getComputedStyle-Technik. Dabei werden Links auf einer Webseite platziert und mittels Javascript ausgelesen, ob diese Links :visited sind. Alter Hut, genauer hier erklärt. Diese Technik ist allerdings in neueren Browsern nicht mehr möglich, die diese das Auslesen des Link-Status verbieten. Trotz allem gibt es noch eine Möglichkeit, um die es hier gehen soll. War der Benutzer bereits auf einer Webseite X, hat er die Bilder dieser Seite in seinem Browsercache. Was muss der Angreifer tun?

Veröffentlicht unter php, Javascript, Security, webdev | Hinterlasse einen Kommentar

Angriffe auf Webanwendungen – Teil 4: CSRF

Vorherige Teile der Serie

CSRF steht für Cross-Site Request Forgery und läuft komplett beim Opfer ab. Das einzige, was der Angreifer tut, ist dem Opfer einen speziellen Link zuzuschicken. GMail war mal anfällig für CSRF-Attacken. Dass klar wird, was sich genau dahinter verbirgt, gibts erstmal ein Beispiel.

Veröffentlicht unter php, Security, webdev | 6 Kommentare

Angriffe auf Webanwendungen – Teil 3: SQL-Injection

Vorherige Teile der Serie

Okay, ich schäme mich fast, darüber noch was zu schreiben. Man möchte doch meinen, dass SQL Injection DER bekannteste Angriff überhaupt ist. Möchte man meinen. Bisher hat sichs aber immer noch nicht bis zum letzten Webentwickler rumgesprochen, weswegen ich hier mal 2 konkrete Beispiele liefere, an denen man herumexperimentieren kann.

Was ist SQL-Inection?

Wenn ein Benutzer der Anwendung die Möglichkeit hat, selbst SQL einzuschleusen spricht man von SQL-Injection. Besonders beliebt sind (gerade in älteren Webanwendungen) das Einschleusen von SQL per $_GET. Beispiel gefällig?

Veröffentlicht unter php, Security, webdev | 2 Kommentare

Angriffe auf Webanwendungen – Teil 2: Session-Highjacking und Session-Fixation

Dieser Post setzt die Kenntnis von XSS und die des PHP Session Managements voraus.

Disclaimer

Ich beschreibe diese Attacke aus Angreifer-Sicht. Wenn man sich in die Rolle des Angreifers hineinversetzen kann, fällt es leichter, weitere Sicherheitslücken zu identifizieren. Ich bin also nicht zur dunklen Seite gewechselt und stifte auch nicht dazu an, es zu tun.

Veröffentlicht unter php, Security, webdev | 8 Kommentare

PHP Session-Management erklärt

Anmerkung: Dieser Post ist dem Teil über Session-Highjacking und Session-Fixation vorgeschaltet, da der Artikel darüber sonst zu lang geworden wäre.

In dem Moment, indem der Benutzer per session_start(); eine Session verpasst bekommt, wird ein Session-Cookie auf dem PC des Benutzers angelegt, der bei jedem folgenden Request wieder an den Server übertragen wird. Dieser Cookie hat den Name PHPSESSID und im Inhalt steht der Session-Name. Der sieht etwa so aus: 3cm12d11d14fg0ssklulk1k274. Dieser Session-Cookie wird verwendet, um den Benutzer wiedererkennen zu können. Mit Firebug oder dem coolen Firefox-Addon Edit Cookies (welches wir später sowieso noch brauchen) lässt sich gut sehen, welche Cookies übertragen werden und was deren Inhalt ist.

Veröffentlicht unter php, Security, webdev | 3 Kommentare