WinFuture-Forum.de: SQL-Injection-Sicherheit - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Entwicklung
Seite 1 von 1

SQL-Injection-Sicherheit


#1 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.765
  • Beigetreten: 11. September 10
  • Reputation: 433
  • Geschlecht:Männlich

geschrieben 09. Juli 2012 - 14:50

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.
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

Anzeige



#2 Mitglied ist offline   __42__ 

  • Gruppe: aktive Mitglieder
  • Beiträge: 38
  • Beigetreten: 10. März 12
  • Reputation: 5

geschrieben 09. Juli 2012 - 20:59

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

#3 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.765
  • Beigetreten: 11. September 10
  • Reputation: 433
  • Geschlecht:Männlich

geschrieben 09. Juli 2012 - 21:27

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?
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#4 Mitglied ist offline   Witi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.940
  • Beigetreten: 13. Dezember 04
  • Reputation: 43
  • Geschlecht:Männlich
  • Wohnort:Kingsvillage
  • Interessen:Frickeln

geschrieben 10. Juli 2012 - 08:32

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.
0

#5 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.765
  • Beigetreten: 11. September 10
  • Reputation: 433
  • Geschlecht:Männlich

geschrieben 10. Juli 2012 - 09:07

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

Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#6 Mitglied ist offline   nobido 

  • Gruppe: aktive Mitglieder
  • Beiträge: 215
  • Beigetreten: 20. April 07
  • Reputation: 9
  • Geschlecht:Männlich
  • Wohnort:Linden (bei Hannover)

geschrieben 10. Juli 2012 - 09:38

Beitrag anzeigenZitat (Holger_N: 10. Juli 2012 - 09:07)

[...] die grundsätzlichen Datenbankberechtigung dort wo es möglich ist einzuschränken.


Auf DB(MS) bzw. Tabellenebene? So per Rolle? (Evtl. kennt das ja jemand von Dynamics AX (2012), da gibt es ein doch recht fein unterteiltes Rollensystem mit dem geregelt wird wer worauf Zugriff hat.)

Was ist mit Parametern? So direkt in die Programmierung integriert? Wird doch gern als ein (All)Heilmittel gegen injections angeführt.
0

#7 Mitglied ist offline   Witi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.940
  • Beigetreten: 13. Dezember 04
  • Reputation: 43
  • Geschlecht:Männlich
  • Wohnort:Kingsvillage
  • Interessen:Frickeln

geschrieben 10. Juli 2012 - 09:42

Beitrag anzeigenZitat (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;
.
0

#8 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.765
  • Beigetreten: 11. September 10
  • Reputation: 433
  • Geschlecht:Männlich

geschrieben 10. Juli 2012 - 11:21

Beitrag anzeigenZitat (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.
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#9 Mitglied ist offline   Witi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.940
  • Beigetreten: 13. Dezember 04
  • Reputation: 43
  • Geschlecht:Männlich
  • Wohnort:Kingsvillage
  • Interessen:Frickeln

geschrieben 10. Juli 2012 - 12:51

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

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0