Nach der WAF nun also die Datenbank-Firewall. Weil dämliche PHP-Programmierer nicht in der Lage sind, sicher auf Datenbanken zuzugreifen, soll GreenSQL zwischen Anwendung und Datenbank heuristisch SQL Injection erkennen. Die Idee ist so blöd, dass ich nicht mal beim szenetypischen Herumalbern darauf gekommen wäre.

Kernproblem bei Injection-Lücken ist die ungenügende Trennung zwischen Daten und Code in Verbindung mit dem Impedance Mismatch zwischen Programmier- und Datenbanksprache. Die kanonische Lösung besteht darin, eben diese Trennung zuverlässig aufrechtzuerhalten. Das lässt sich recht einfach bewerkstelligen, indem man eine geeignete Programmierschnittstelle − Prepared Statements statt Stringverkettung zu SQL-Statements − verwendet. Das kann zwar auch noch schiefgehen, wenn die Bibliotheksfunktion Fehler hat, aber wenigstens kann man sich selbst nicht mehr in den Fuß schießen.

Ist die Grenze zwischen Code und Daten einmal verwischt, steht die Datenbankfirewall vor exakt demselben Problem wie die Datenbank selbst: sie kann diese Grenze nicht mehr zuverlässig bestimmen. Konzeptionell ist die Datenbankfirewall deswegen genauso machtlos wie die Zugriffskontrolle der Datenbank. Sie versucht es nur mit einer anderen Strategie. Klüger wäre es, den Entwicklern ausschließlich sichere Schnittstellen zur Verfügung zu stellen.

Als Security-Theater allerdings dürfte so eine Datenbankfirewall hervorragend funktionieren, spuckt sie doch am laufenden Band Meldungen aus, die MovieOS alle Ehre machen würden: Hilfe, wir werden angegriffen!