Sep 8, 2009

substr(md5($x), 0, 8) == viel mehr Kollisionen

MD5 ist nicht für alles geeignet, aber noch viel schlimmer ist ein gekürtzter MD5.

Deswegen warte ich schon seit ewigkeiten auf folgenden Patch:

http://bugs.typo3.org/view.php?id=10201

Und was sehe ich heute morgen beim täglichen SVN check, der Core wurde angepasst:

http://forge.typo3.org/repositories/revision/27/5910

Das hat schon einige Kopfschmerzen verursacht, wenn plötzlich cHashes kollidieren, also nicht mehr eindeutig sind. In Kombination mit RealURL kann dies ganz lustige Phenomene hervorbringen.

View → tages / typo3 / core / security

Aug 25, 2009

XXS Code entfernen in rekursiven Arrays

Dieser Patch zeigt sehr schön, wie alle Extensions Ihr Süppchen kochen. Eine removeXSS Methode in der commerce_div Klasse (t3lib_div Geschwister) über mehrdimensionale Arrays. Vorbildlich ist, dass Ingo die “offizielle” TYPO3 removeXSS methode verwendet hat. Ich verstehe ihn auch total; Diese removeXSSStripTagsArray() methode in die t3lib_div zu bekommen, wäre ein Ding der Unmöglichkeit deswegen gibt es ja auch commerce_div.

Gut wäre eine allgemeine Security Klasse, in die man solche Funktionalität steckt, das ist aber wieder eine Funktionssammlung und kein wirkliches OOP…

Oder sollte man doch eher eine “User Input String” Klasse machen welcher man sagen kann was es sein soll und was es einem geben soll, z.B.:

$keyword = new UserInput($this->piVars[‘keyword’]);

$markers[‘###KEYWORD###’] = $keyword->getXSSEscaped();

… sql … WHERE keyword LIKE ‘%”.$keyword->getSQLEscaped().”%’ …

Oder noch besser, man bekommt an stelle eines piVar Arrays einfach UserInput Objekte, denen man sagen muss wie man den Inhalt möchte.

$name = $this->getUserInput(‘nam’);

$name->getSQLEscaped();

Apropos, wo filtert/escaped Ihr den User Input in Euren Extensions? Dort wo Ihr diesen nutzt oder dort wo Ihr in vom TYPO3 bekommt?

Es gibt so viele Varianten und man könnte Stunden darüber diskutieren ;-)

View → tages / security / commerce / typo3 / sql / escape / library