Sicherheit durch Stored Procedures

Bei meiner Beschäftigung mit SQL in letzter Zeit bin ich auf einen relativ alten Trick gestoßen, um die Sicherheit von Programmen zu erhöhen. Dazu speichert man sämtliche für das Programm benötigten Queries als Stored Procedures in der Datenbank. Das PHP-Programm bekommt als einziges Recht EXECUTE PROCEDURE und alle anderen Rechte werden im entzogen. Sogar falls die Netzseite mit dem PHP-Programm gehackt wird und das PHP-Programm umgeschrieben, lassen sich auf der Datenbank trotzdem nur die vorgesehenen Queries ausführen.

Ein bißchen suspekt ist mir nur, daß eine Datenbank genau so leicht oder schwer zu knacken sein dürfte wie der Rest einer Netzseite. Wenn ein Webhoster viele sicherheitskritische Funktionen anbietet, dann kann ein Angriff darauf vielleicht schon viel mehr Schaden anrichten als auf die Datenbank. Schon der Mißbrauch von mailto() könnte dafür sorgen, daß man vom Hoster rausgekickt wird und dann wäre man auch von seiner Datenbank getrennt. Darum frage ich mich gerade, ob sich der Wechsel zu Stored Procedures lohnt. Wo es nur um Queries geht, bleiben die sowieso gleich. Transaktionen erfordern weniger Kommunikation zwischen PHP-Parser und MySQL, wenn die sich in einer Stored Procedure befinden. Falls man die Wahl zwischen Stored Procedure oder dem gleichen Programmteil als PHP hat, dann soll PHP bei der Verarbeitung von Zeichenketten und mathematischen Funktionen schneller sein, sonst nicht. Die Geschwindigkeit wäre schon der einzige Vorteil.

Ich überlege außerdem so Sachen wie CSS statt in eine Datei in die Datenbank zu verlegen. Da könnten dann, falls erforderlich oder sinnvoll, ein paar Fallunterscheidungen noch per Stored Procedure getroffen werden und dann der CSS-Teil an das PHP-Skript ausgeliefert werden. Der Grund für die Verlegung wäre natürlich nur der, daß Datenbanken angeblich schneller gelesen werden können als Dateien. Dazu muß ich aber noch anmerken, daß das meiner bisherigen Erfahrung nicht entspricht. Bei einer Netzseite mit mehreren parallel zugreifenden Besuchern kann sich das natürlich schnell ändern.
Ranma

Auch sicherheitskritische PHP-Funktionen lassen sich ggf per disable_functions in der php.ini einschränken

Schön. Aber wenn ich sie brauche? Man sucht lange nach einem Webhoster, der solche Funktionen zuläßt. Wenn man einen gefunden hat, dann wird man die Funktionen kaum selbst abschalten. Wenn sie nur für bestimmte Skripte gestattet wären, das wäre natürlich genial. Zum Beispiel verbieten alle den Versand von Späm-Emails. Aber es gibt praktisch nur Hoster mit entweder eingeschaltetem mailto() oder abgeschaltetem mailto(), während man vergeblich danach sucht, daß nur massenhaft versandte Emails unmöglich, aber ein bis zwei pro Tag erlaubt sind.

Die Angriffsfläche auf MySQL einzuschränken, ist natürlich gut. Aber wieso hat sich die Methode dann nicht durchgesetzt?

Ist die Sicherheit nur eine Illusion und GRANT oder SQLSECURITY bleiben ausführbar? Ist SQL sehr langsam? Meine Stored Procedure zur Umsortierung der Datenbanktabellen weist jedenfalls darauf hin. Oder ist der Trick doch nicht so alt? Ich habe die widersprüchlichen Angaben gefunden, daß SQL keine Programmiersprache sei und SQL wäre Turing-vollständig und darum könne man alles damit programmieren, was man in anderen Programmiersprachen auch programmieren kann. Dann unterscheiden manche noch zwischen SQL und der Stored-Procedure-Programmiersprache, die dann nur aus den Kontrollstrukturen besteht. Die kamen wohl erst später dazu. Deshalb gilt der Interpreter als noch nicht so weit optimiert wie der von PHP oder anderen Programmiersprachen und SQL ist wohl tatsächlich sehr langsam.

Sicherheit dürfte wohl generell höher zu gewichten sein als Geschwindigkeit. Aber wer meine Netzseite cracken kann, der kann ja sicherlich auch meine Datenbank cracken? Eigentlich fürchte ich mich vor letzterem weniger als vor ersterem.
Ranma

Zum Programmieren würde ich SQL nicht verwenden.

Wieso nicht? Legst du nicht so viel Wert auf Sicherheit?

Angeblich wird bei größeren Unternehmen datenbanknah programmiert, also mit SQL, um Portabilität zu gewährleisten. Da greifen dann mit unterschiedlichen Programmiersprachen geschriebene Programme auf die selben Datenbanken zu. Für mich erstmal kein Grund.

Die Geschwindigkeit spricht natürlich gegen Programmierung in SQL. Außer wenn dadurch die Anzahl der Zugriffe auf die Datenbank reduziert wird.
Ranma

Jetzt mußte ich mich erstmal darüber schlau machen, was an Ada so toll ist. Tatsächlich hat Ada sich nur deswegen durchgesetzt, weil es einige Zeit lang vom US-Verteidigungsministerium gefördert wurde, das auch für einen kostenlosen Compiler gesorgt hat.

Möglicherweise taugt ein SQL-Skript für einen Crawler, weil der nicht mit Endnutzern interagiert, aber viele Datenbankeinträge macht. Nur eine passende Funktion, um HTML-Dateien einzulesen fehlt mir dafür noch. Vielleicht ist im SQL doch nicht alles vorhanden....
Ranma