Zur Navigation

Sicherheit durch Stored Procedures

1 Ranma (Gast)

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

28.12.2015 08:02

2 Jörg

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.

Mit den Stored Procedures verringerst du die Angriffsfläche, das kann man denke ich schon als sinnvoll ansehen. Auch sicherheitskritische PHP-Funktionen lassen sich ggf per disable_functions in der php.ini einschränken

Der Grund für die Verlegung wäre natürlich nur der, daß Datenbanken angeblich schneller gelesen werden können als Dateien.

Ich denke, das kommt darauf an. Wenn es nur darum geht, eine Datei anhand des Dateinamens zu laden, dann ist das Dateisystem vermutlich schneller. Wenn es auch um Durchsuchbarkeit oder weitergehenden Suchkriterien geht, dann ist wohl die Datenbank im Vorteil.

28.12.2015 20:57

3 Ranma (Gast)

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

29.12.2015 02:51

4 Jörg

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.

Man kann mit disable_functions einzelne Funktionen abschalten.

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

Es ist halt immer auch die Frage des Aufwandes, den man betreiben möchte, bzw. in welchem Verhältnis Aufwand und Sicherheit stehen sollen.

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.

Zum Programmieren würde ich SQL nicht verwenden. Ab wann PHP schneller ist, lässt sich auch durch Benchmarks herausfinden, z.B. mit microtime (siehe Beispiel #2)

Aber wer meine Netzseite cracken kann, der kann ja sicherlich auch meine Datenbank cracken?

Theoretisch. Erst mal muss eine Lücke gefunden werden, die ausgenutzt werden kann. Je weniger Angriffsfläche die Applikation bietet, umso unwahrscheinlicher ist ein Einbruch.

29.12.2015 20:56

5 Ranma (Gast)

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

30.12.2015 06:54

6 Jörg

Zitat von Ranma
Zum Programmieren würde ich SQL nicht verwenden.

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

Diese Antwort bezog sich auf die Feststellung, dass SQL turing-vollständig ist, man eine Applikation also vollständig in SQL programmieren könnte. Dafür würde ich SQL nicht einsetzen, weil es eine Sprache ist, die für die Verwaltung von Datenbanken konzipiert ist, und nicht für die Erstellung von Webseiten, wofür PHP die geeignetere Sprache ist, weil genau dafür konzipiert. Für Software, bei der Sicherheit eine sehr große Rolle spielt, weil sie z.B. in Kernkraftwerken eingesetzt wird, wäre wiederum Ada eher eine geeignete Sprache.

Es gibt natürlich Schnittmengen zwischen Datenbank- und Script-Sprache. Wenn man FOREIGN KEY Constraints in der Datenbank anlegt, muss sich an der Stelle nicht das PHP-Script um die Konsistenz der Daten kümmern. Das macht die Datenbank auch portabler weil unabhängiger vom Script, wenn sie sich weitergehend selbst verwaltet.

02.01.2016 15:10

7 Ranma (Gast)

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

04.01.2016 01:34

8 Ranma (Gast)

Eine Verbindung zu einem anderem Server herzustellen ist so ziemlich das Einzige, das eine Stored Procedure nicht kann.
Ranma

05.01.2016 02:17

Beitrag schreiben (als Gast)





[BBCode-Hilfe]