AOit Linux Admin Blog

Mittlerweile ist die offizielle Version 2.0 von Cakephp erschienen.

Ein paar kurze Eckdaten:

• Performance ca. 50% schneller gegenüber Cakephp 1.3 (liegt stark am neuen lazy-loading und das der PHP4 Support weggefallen ist)
• PHPUnit als Testframework
• Download: https://github.com/cakephp/cakephp/tarball/2.0.0
• Dokumentation: http://caky.de

Wenn man mit Git arbeitet möchte man irgendwann einmal Code von anderen importieren.
Zum Beispiel um ein Plugin in seine Cakephp Applikation zu importieren. Oder man hat selbst verschiedene Projekte und möchte bestimmten Code wiederverwenden. Bei uns haben wir zum Beispiel das Frontend für unsere Kunden und das Backend für die Administratoren komplett von einander getrennt. Aber z.B. der CSS Code ist in beiden Projekten nahezu gleich. Und auch bestimmte Plugins kommen in beiden vor. Es wäre ein fast unmöglicher Aufwand in beiden Projekten immer den identischen Code zu haben.

Daher haben wir ein Konzept gefunden wie man mit solchen Abhängigkeiten flexibel umgehen kann.

$ cd mein-projekt
$ git clone <url-anderes-projekt> mein-unterprojekt
$ git add mein-unterprojekt/

Wichtig ist hierbei das beim letzten Befehl auch ein / am Ende steht. Andernfalls versucht Git den eigenen viel komplexeren Submodul-Modus zu benutzen.

Jetzt hat man praktisch zwei verschachtelte Git Repositorys. Wenn man nun das Unterprojekt updaten will, geht man wie folgt vor:

$ cd mein-unterprojekt
$ git pull

Das funktioniert weil immer das näherliegende .git Verzeichnis benutzt wird. Ein weiterer großer Vorteil ist das wir das Unterprojekt an unsere Projektbedürfnisse anpassen können.

Ein kleiner Wermutstropfen tritt auf wenn ein anderes Projektmitglied den Code vom Hauptprojekt "cloned". Der Code vom Unterprojekt ist zwar enthalten, aber nicht die direkte Abhängigkeit zum Unterrepository. Das lässt sich aber relativ einfach lösen in dem man bei Änderungen dann einfach den Ordner löscht mit "rm -Rf mein-unterprojekt" und wie oben gezeigt wieder neu cloned. Daher packen wir in jedem von uns angelegten Unterprojekt auch eine Readme mit den nötigen URL Infos hinein.

Wie in unserem Beitrag "Datenschutz mal richtig umsetzen" geschrieben sollte man aufsteigende (z.B. MySQL autoincrement) ID Primary Felder vermeiden. Wenn man sich ein wenig umschaut merkt man schnell das UUIDs diesen Zweck erfüllen könnten.

Zwar sind diese eigentlich aus einem ganz anderen Grund erfunden worden, aber warum das Rad neu erfinden wenn ein Quasi Standard auch den Zweck erfüllt. Nebenbei erhält man damit auch die Möglichkeit Datensätze unabhängig (offline) vom MySQL Server zu erzeugen. Denn man erzeugt ja nun selbst die Primary ID und wenn man sich an den UUID Standard hält sollten auch keine Konflikte auftreten.

Unter Cakephp geht das ganze auch sehr Schmerzfrei indem man einfach das ID Feld statt mit int(11) mit char(36) anlegt. Dann kümmert sich Cakephp selbständig um die Erzeugung der UUID Nummern.

Git (dezentrales Versionsmanagement) hat eine tolle Funktion um Verzeichnisse aus der Versionierung auszuklammern. Man trägt einfach Zentral in der .gitignore die Dateien ein die man nicht mit versionieren möchte. Für Cakephps tmp Verzeichniss sieht das dann z.B. so aus:

tmp/*
tmp/logs/*
tmp/sessions/*
tmp/tests/*
tmp/cache/*
!tmp/cache/empty
tmp/cache/models/*
!tmp/cache/models/empty
tmp/cache/persistent/*
!tmp/cache/persistent/empty
tmp/cache/views/*
!tmp/cache/views/empty

Die Einträge mit einem ! bedeuten das genaue Gegenteil (sprich diese Dateien werden wieder in die Versionierung aufgenommen). Da GIT keine (leeren) Ordner verwaltet braucht man diese leeren empty Dateien. Das Beispiel ist nicht vollständig, da man auch die Config Dateien unter Umständen auschließen möchte.

http://www.heise.de/security/meldung/Datenpanne-Unesco-entbloesst-Bewerber-im-Netz-1234573.html

Anlässlich dieses Vorfalls möchte ich einmal die technischen Gegenmaßnahmen erläutern die einen solchen Vorfall verhindert hätten. Also zunächst worum ging es genau.

Gegeben sei ein Login Bereich wo nur registrierte und eingeloggte Nutzer Zugriff haben. Nach dem Login kann der Nutzer seine Daten einsehen und ggf. bearbeiten. Der Aufruf seiner Daten erfolgt über folgende URL:

http://example.net/user.php?id=120

oder eine Seite die z.B. mod-rewrite nutzt:

http://example.net/user/120

Wie man sehen kann steht mit hoher Wahrscheinlichkeit die 120 für die Zuordnung zur ID des (MySQL) Datensatzes.

Natürlich kann im Hintergrund auch jede andere Art von persistenter Datenspeicherung erfolgen. Jetzt könnte man mit dieser ID ein wenig rumspielen und den Wert um eins erhöhen oder verringern:

http://example.net/user/121
http://example.net/user/119

Wenn die Anwendung nun nicht prüft ob die ID vom User überhaupt abgerufen werden darf, kann jemand relativ simpel alle Datensätze anderer User auslesen. Und genau das ist auch der Unesco passiert es wurde zwar Authentifiziert (Registrierung und Login) und evtl. sogar der Zugriff gruppentechnisch per ACL autorisiert, aber es wurde vergessen den Zugriff auf die einzelnen Datensätze des entsprechenden Nutzers einzuschränken.

Welche Lösungen gibt es so etwas zu verhindern?

1. Die ID als mehrstellige Zufallszahl ausführen
Das könnte dann so aussehen:

http://example.net/user/eachaeso1tie
http://example.net/user/aimizoh9oosu

Nun ist es für jemanden ohne interne Kenntnisse schwierig weitere IDs auf anhieb zu erraten. Aber auch nicht unmöglich. Denn eine Brute Force Attacke wäre auch hier noch erfolgreich. Auch muss man sich selbst um die Generierung der ID kümmern und dafür sorgen das keine Dubletten generiert werden. Ein weiterer kleinerer Nachteil liegt auch in der Performance. Allerdings kann man Brute Force Attacken sehr leicht erkennen und z.B. nach drei Fehlgeschlagenen abrufen den User sperren.

2. Ordentliche Rechteprüfung ob der Nutzer die Daten überhaupt abrufen darf
Schon etwas aufwendiger je nach zu Grunde liegender Architektur ist die saubere Prüfung ob der Datensatz dem Nutzer gehört.
Richtig sauber wird es dann wenn man auch hierbei fehlgeschlagene Abrufe loggt und somit ggf. komprimierte Logins aufdeckt und frühzeitig sperren kann.
Bei einem öffentlichen Dienst mit freier Registrierung ist es natürlich nur eine Frage der Zeit bis der Angreifer ein frisches Konto hat.

Der Grund warum so etwas immer wieder vorkommt ist wahrscheinlich die trügerischer Sicherheit das der Login schon autorisiert ist und der Kunde/Endnutzer nicht weiß wie schnell man seine Daten ausspähen kann. Bei Cakephp lassen sich diese Konzepte wunderbar z.B. in das entsprechende Model unterbringen/abstrahieren.

Wir haben einmal unter http://caky.de die aktuellste Dokumentation zu Cakephp 2.0-alpha hochgeladen.

Es ist mal wieder ein Update der 1.3er Serie von Cakephp veröffentlicht worden:

http://bakery.cakephp.org/articles/markstory/2011/01/19/cakephp_1_3_7_released