Dependency Injection – kurz erklärt
Dependency Injection – klingt nach professioneller Programmierung. Aber was ist das eigentlich?
Wenn man nach Dependency Injection sucht, gibt es fast ausschließlich komplexe Erklärungen, die man nicht auf Anhieb versteht. Deshalb gibt es an dieser Stelle eine möglichst einfache Erläuterung von Dependency Injection in PHP.
Nehmen wir einmal an wir haben eine Klasse Gästebuch, die beim instanziieren ein Datenbank-Objekt erwartet.
class Guestbook { /** * @var DatabaseDriver */ protected $db; public function __construct(DatabaseDriver $db) { $this->db = $db; } } |
Jetzt ist es aber aufwendig bei jeder Erzeugung eines neuen Gästebuchs das Datenbank-Objekt zu übergeben, vor allem weil die Datenbank bei allen Gästebüchern die gleiche ist. Also wurde das Entwurfsmuster Dependency Injection entwickelt, das diese Vorgehen vereinfachen soll.
class Guestbook { /** * @var DatabaseDriver * @inject */ protected $db; public function __construct() { $result = $this->db->query("SELECT * FROM guestbook"); ... } } |
Dieses Beispiel funktioniert natürlich nicht ohne Weiteres, es zeigt aber die Idee hinter DI. Durch zum Beispiel die Angabe der Annotation @inject wird angezeigt, dass die Datenbank noch vor der Instanziierung von Guestbook eingefügt werden soll und wir damit quasi sofort arbeiten können.
In PHP gibt es diverse Frameworks, die das DI-Entwurfsmuster bereits implementieren. Dazu gehören unter anderem FLOW3, Zend Framework 2 und Symfony 2, aber eine wirklich saubere Lösung ist meiner Meinung nach noch nicht dabei. Bei FLOW3 beispielsweise werden die eigentlichen Klassen durch Fake-Klassen “überschrieben”, in denen dann das Inject vollzogen wird.
Wer DI also nutzen will, braucht in jedem Fall eine Logik, die das Inject überhaupt ausführt. Ohne Framework keine leichte Aufgabe.
Unsinnige Sprachkonstrukte und Funktionen in PHP?
In PHP exisitieren unheimlich viele Kontrollstrukturen und Funktionen. Klar, dass es dabei auch einiges gibt was man im Alltag eigentlich gar nicht braucht oder sauberer lösen kann oder vielleicht sogar unsinnig ist.
Mit den folgenden fünf Kontrollstrukturen musste ich persönlich noch nie arbeiten:
5 Gefahrenquellen in PHP-Anwendungen
PHP-Anwendungen sind bekannt dafür viele Sicherheitsmängel zu beinhalten (obwohl das nicht stimmt), trotzdem möchte ich heute einmal auf 5 der schwersten Sicherheitslücken aufmerksam machen. Schaut euch doch mal eure (älteren) PHP-Skripte an. Die meisten werden mindestens eine dieser 5 möglichen Gefahrenquellen wiederfinden 
- Daten, die aus der Datenbank kommen, sind sicher
Grundsätzlich sollte auch die Datenbank als “Benutzer” betrachtet werden und auch hier alle eingehenden Daten überprüft werden (z.B. wenn die Daten zur Generierung von neuen PHP-Code oder dem Laden von Dateien genutzt wird).
Der Grund ist ganz einfach: Sollte ein Unbefugter Zugriff auf die Datenbank erlangen, könnte er damit evtl. auch direkt das Verhalten der PHP-Anwendung beeinflussen. - Prepared Statements oder Escaping machen SQL-Injections unmöglich
Über Best Practices gegen SQL-Injections habe ich bereits berichtet. Es reicht nicht aus nur Spaltenwerte mit Prepared Statements zu schützen. Auch Spalten-, Tabellennamen und alles was sonst noch vom Benutzer zur Datenbank gelangt, kann eine SQL-Injection enthalten. - Session IDs, die in Cookies abgelegt sind, können nicht ausgelesen werden
Das Standard-Verzeichnis für PHP-Sessions lässt sich von jedem, der ebenfalls einen Host auf dem Server hat, auslesen – ein Kinderspiel um an die IDs der Sessions zu gelangen. Verhindern lässt sich das am besten, in dem man ständig die IP-Adresse überprüft der Session abfragt, die Session-ID jedes mal gewechselt wird (session_regenerate_id()), oder man ein anderes Verzeichnis wählt (session_save_path()). - Zugangsdaten zur Datenbank werden am sichersten in einer PHP-Datei abgelegt
Die Aussage an sich ist natürlich völlig richtig, aber was passiert wenn die Datenbank plötzlich einen Fehler meldet und die Zugangsdaten über eine unglücklich programmierte Fehlerbehandlung zu Debugging-Zwecken ausgegeben wird? - Mit MD5 verschlüsselte Passwörter sind sicher
MD5-Hashes lassen sich mittlerweile kinderleicht über Hash-Datenbanken oder Rainbow-Tables knacken. Abhilfe schaffen Salted Passwörter oder verbesserte Verschlüsselungsmethoden wie beispielsweise RSA.
Nicht alle der fünf hier genannten Punkte sind selbstverständlich und manchmal denkt man auch nicht daran, dass so etwas ausgenutzt werden könnte. Daher macht es Sinn sich einmal selbst in die Rolle des Angreifers zu versetzten und zu versuchen seine eigene Anwendung mit allen Möglichkeiten zu hacken. Immerhin kennt man sich selbst mit seinem selbstgeschriebenen Code noch am besten aus.
Ältere Artikel »