Dr. Christopher Kunz

Seit einiger Zeit gibt es an dieser Stelle wenig Kohärentes von mir zu lesen. Das liegt zum Einen daran, daß ich viel von den unausgereiften Gedanken auf Twitter einkippe, aber vor allem daran, daß ich schlicht nicht die Muße habe, mich in aller Ausführlichkeit in einem Blogartikel zu äußern. 

Nun habe ich in den letzten Monaten verstärkt an meiner Dissertation gearbeitet, so daß sich die Funkstille hier zumindest auszuzahlen scheint. Letztes Wochenende, genauer gesagt am Freitag abend im ICE nach Hamburg, fiel mir dann mehr zufällig auf, daß ich gerade das letzte Kapitel fertig geschrieben hatte - Zusammenfassung und Ausblick. Nun ist in jedem Kapitel zumindest Inhalt ungefähr in dem Umfang und in der Zusammensetzung, wie ich es mir vorgestellt hatte.

Das Ganze sieht dann so aus (nach dem Break):

While deploying Suhosin on all of de-punkt’s hosting servers, I noticed domains suddenly go 403 on me. After quick investigation, mod_security seemed to be the issue, I was seeing lots of

[Mon Nov 13 10:43:24 2006] [error] [client 217.188.206.51] mod_security: Access denied with code 403. Pattern match “!^[0-9a-z]*$” at COOKIE(“PHPSESSID”) [hostname “www.mycustomer.com”] [uri “/”] [unique_id “RVg@PD4ESo4AACcOrJg”]

log messages. Unnecessary to mention that mod_security’s configuration had not be touched. The rule in question is part of the popular ruleset from gotroot.com.

The reason for this is that the whole cookie is transparently encrypted by Suhosin’s cookie encryption feature and the session ID is no longer alphanumeric (since it’s encrypted). Mod_security sees a weird-looking cookie parameter in each request and denies it with the configured response code (which, in our case, is 403).

You can fix the problem by disabling this rule:

SecFilterSelective COOKIE_PHPSESSID “!^[0-9a-z]*$”
SecFilterSelective COOKIE_sessionid “!^[0-9a-z\.]*$”

Just a quick heads-up for everyone who might run into similar problems (like with the Zend platform, that assings “non-standard” session IDs as well). We will mention this in the mod_security and Suhosin chapters in the upcoming second edition of “PHP-Sicherheit”.

Der Kontext dieses Blog-Eintrages
von Bruce Schneier ist nicht direkt PHP-bezogen, jedoch ist ein
erfolgreicher Angriff gegen die SHA1-Hashfunktion aus sicherheitstechnischer Sicht eine Sensation. Das noch nicht öffentlich
vorliegende Paper eines chinesischen Teams von Cryptanalysten
beschreibt offenbar einen Weg, die SHA1-Hashfunktion mittels
Kollisionen o.ä. anzugreifen. Damit wäre nicht nur die PHP-Funktion
sha1(), sondern u.a. auch der Signierungsmechanismus von PGP/GnuPG gefährdet, der von Programmierern oft eingesetzt wird, um sensitive
Daten automatisch mit einem verifizierbaren Merkmal auszustatten.
Die Anzahl benutzbarer und starker Hashing-Algorithmen konvergiert damit unaufhaltsam gegen Null, was sicherheitsbewußte Anwender und Entwickler nicht eben fröhlich stimmen dürfte.