[Holger_N]

Ich überlege gerade, ob es nicht total einfach wäre, Datenbankverbindungen (natürlich nur dort wo es auch geht, also bei reinen Abfragen) einfach über Zugänge zu machen wo der entsprechende Datenbankbenutzer dann von vornherein nur eine Leseberechtigung hat. Da dürfte doch dann gar nix per Injection gehen oder?
Bei sämtlichen Sicherheitstipps hab ich aber neben der PDO und Prepared Statement Geschichte bislang nur immer allerhand Möglichkeiten zur Kontrolle der übergebenen Variablen gefunden. Das wäre doch aber total einfach mit dem beschränkten Zugang, wenn es denn ginge.

[__42__]

Das schützt die Datenbank zwar vor Veränderung, aber nicht vor unbefugtem Auslesen der Daten.

[Holger_N]

Na das Auslesen soll ja auch erlaubt sein. Ein Beispiel wäre eine ganz normale Webseite mit Suchfunktion. Die Inhalte stehen in einer Datenbank und dürfen logischerweise auch von jedem auf der Seite angesehen werden. Über eine Suchfunktion kann man nun nach Stichwörtern im Inhalt suchen. Wenn man jetzt zu leichtsinnig programmiert hat, könnte man ja über das Eingabefeld des Suchwortes solch eine Injektion durchführen. Wenn nun aber von vornherein gar keine Schreibberechtigung existiert, dürfte ein entsprechende Injektion doch wirkungslos sein oder?

[Witi]

Stell dir vor du hast eine Tabelle mit Benutzern, in der du auch Passwörter hinterlegst. Deine Suchfunktion, die überhaupt nichts mit der Benutzer-Tabelle zu tun haben könnte, weil sie ganz andere Tabellen ausliest, hat eine Injection-Lücke. Trotzdem wäre es einem geschickten Angreifer möglich deine gesamte Benutzertabelle zu exportieren. Und was das heißt, muss ich sicherlich nicht näher erläutern.

[Holger_N]

Aha man kann dann die Tabellen also trotz Nur-lese-Zugriff exportieren. Ich muß das nochmal näher aufdröseln. Ich persönlich würde die Idee ja als zusätzlichen Schutz betrachten, nicht als Alleinigen. Das obige Beispiel war jetzt nur für eine Datenbanktabelle, wo prinzipiell eine reine Leseberechtigung ausreichen würde, weil das reine Auslesen ja gewollt ist und nicht unbefugt wäre.
Wenn man also zu leichtsinnig programmiert, bietet das natürlich keinen wirklichen Schutz aber als zusätzliche Barriere würde es doch Sinn machen, die grundsätzlichen Datenbankberechtigung dort wo es möglich ist einzuschränken.

Dieser Beitrag wurde von Holger_N bearbeitet: 10. Juli 2012 - 09:09

[Witi]

Zitat (Holger_N: 10. Juli 2012 - 09:07)

Aha man kann dann die Tabellen also trotz Nur-lese-Zugriff exportieren.

Mit Exportieren meine ich eine normales SQL-Statement was mir einfach alle Daten einer Tabelle liefert.

Ansonsten gebe ich dir recht, wenn du in dieser Tabelle - nachdem die Daten alle enthalten sind - ausschließlich lesen zugreifst, ist es sicherlich nicht verkehrt sie auf "read-only" zu setzen. Das würde ich dann direkt über SQL lösen, also in etwa so:

GRANT SELECT ON db.table TO user;

.

Möglicherweise - da bin ich mir jetzt nicht wirklich sicher - musst du aber auch den umgekehrten Weg gehen und die entsprechenden Rechte entziehen, also:

REVOKE INSERT,UPDATE,DELETE,DROP ON db.table FROM user;

.

[Holger_N]

Zitat (Witi: 10. Juli 2012 - 09:42)

Mit Exportieren meine ich eine normales SQL-Statement was mir einfach alle Daten einer Tabelle liefert.

Ansonsten gebe ich dir recht, wenn du in dieser Tabelle - nachdem die Daten alle enthalten sind - ausschließlich lesen zugreifst, ist es sicherlich nicht verkehrt sie auf "read-only" zu setzen. Das würde ich dann direkt über SQL lösen, also in etwa so:

GRANT SELECT ON db.table TO user;

.

Möglicherweise - da bin ich mir jetzt nicht wirklich sicher - musst du aber auch den umgekehrten Weg gehen und die entsprechenden Rechte entziehen, also:

REVOKE INSERT,UPDATE,DELETE,DROP ON db.table FROM user;

.

Na meine Idee eigentlich die, dass man direkt für die Datenbank schon verschiedene Benutzer anlegt und wenn per PHP die Datenbankverbindung hergestellt wird, entsprechend der Rechte von vornherein nur ein Datenbankaccount verwendet wird, der nur Leserechte hat.

[Witi]

Ja, ja klar. Das kannst du natürlich auch machen.