Unter:

http://www.nextgenss.com/papers/advanced_sql_injection.pdf

findet man eine sehr gute Doku über Sicherheitslücken in SQL Abfragen in ASP, PHP etc. Ist mit Sicherheit auf andere ähnliche (Script-)Sprachen übertragbar.

Sehr gute Beispiele, die einen über die eigenen Anwendungen grübeln lassen...

Sehr interessant und ernstzunehmen!!!

Ossi

Hi,

das ist eine ganz interessante Sache, setzt aber ein paar Dinge voraus:

Windows, MS SQL-Server und einen der diese Scripte entwickelt hat ohne jegliche Datenvaliditätsprüfung VOR dem Datenbankzugriff. Will ja nicht sagen, das andere Systeme sicherer sind, aber ein derart offenes script wie in diesem Beispiel lässt das natürlich ohne weiteres zu.

Lösungsvorschläge fehlen mir da noch, aber die kann man auch selber finden.

MfG:)

Original geschrieben von DanielH

Lösungsvorschläge fehlen mir da noch, aber die kann man auch selber finden.

Mir war das Problem auch schon länger bewußt, aber nach (kompletter) Lektüre des Dokumentes bin ich mir gar nicht mehr darüber im klaren, wie sicher meine (und so manch andere) Scripte noch sind. Man braucht *sehr* viel SQL-Server-Know-How, um alle Möglichkeiten der SQL-Injection zu verhindern.

Grüße

Matze

Ich kann mir aber kaum vorstellen, dass ein einfaches Script Rechte zum Löschen der USERS-Tabelle besitzt.

Bei einer MySQL-Datenbank ist dies jedenfalls nicht möglich, da kann nur der Admin in der USERS-Tabelle rumfummeln.

Original geschrieben von bohni

Ich kann mir aber kaum vorstellen, dass ein einfaches Script Rechte zum Löschen der USERS-Tabelle besitzt.

Bei einer MySQL-Datenbank ist dies jedenfalls nicht möglich, da kann nur der Admin in der USERS-Tabelle rumfummeln.

Es muss ja nicht so weit gehen. Alleine schon das Ausspähen, Manipulieren oder Löschen von Daten einer Anwendung kann extreme Schäden zur Folge haben. Wird das System kompromittiert, ist natürlich alles verloren.

Dass bei einer mySQL-Datenbank solche Aktionen nicht möglich sind, kann man aber auch dadurch erklären, dass mySQL im Vergleich zum SQL-Server eher ein Spielzeug für Webseiten ist. Wo kein Feature ist, da kann auch kein Feature-Mißbrauch statt finden. Und der SQL-Server strotzt nur so von - in der Tat äußerst hilfreichen - Features. (Kein Flamewar jetzt bitte.)

Wenn Du dich mit SQL-Server, MSDE und sonstiger Programmierung vor allem in VB auseinandersetzt, dann stösst Du immer wieder auf das Beispiel, dass man sich an der Datenbank mit dem User "sa" (also Scheffe) ohne Passwort anmeldest. Dies sind die Standard-Einstellungen bei der Installation, was man natürlich gerne kritisieren darf. Es gibt BTW schon mindestens einen Wurm, der dies ausnutzt. Dur wirst dort draußen tausende Server finden, die derart konfiguriert sind.

Fazit kann nur sein: Wer sein System mit Unwissenheit aufsetzt und vor allem ohne die Dokus zu lesen, fährt fahrlässig und vielleicht gegen die Wand. Das gilt bei Microsoft-Produkten ganz besonders.

Gruss

Matze

Das ist aber schon fast fahrlässig von Microsoft, ein Server-System mit so niedrigen Sicherheitseinstellungen als Standart anzubieten. Vielleicht sollten die mal lieber paar sogenannte Features zu Gunsten der Sicherheit weglassen. Aber die Marketing-Politik sieht das wahrscheinlich anders, lieber ein einfach und schnell zu installierendes System für die breite Masse, wo dem Administrator sofort ein Erfolg beschert wird, als vielleicht ein etwas schwierigeres zu administrierendes System, wo später noch mehr Konfigurationsarbeit zu bewältigen ist.

Komischerweise hört man von Oracle-Datenbanken äusserst selten von so gravierenden Lücken. Könnte am höreren Administrationsaufwand und der spezielleren Konfiguration liegen.

Original geschrieben von bohni

Das ist aber schon fast fahrlässig von Microsoft, ein Server-System mit so niedrigen Sicherheitseinstellungen als Standart anzubieten. Vielleicht sollten die mal lieber paar sogenannte Features zu Gunsten der Sicherheit weglassen. Aber die Marketing-Politik sieht das wahrscheinlich anders, lieber ein einfach und schnell zu installierendes System für die breite Masse, wo dem Administrator sofort ein Erfolg beschert wird, als vielleicht ein etwas schwierigeres zu administrierendes System, wo später noch mehr Konfigurationsarbeit zu bewältigen ist.

Komischerweise hört man von Oracle-Datenbanken äusserst selten von so gravierenden Lücken. Könnte am höreren Administrationsaufwand und der spezielleren Konfiguration liegen.

Ich denke, du hast den Kern des ganzen nicht erfasst.

Auch ein MS-Produkt will konfiguriert werden. Die Standard-Einstellung des Adminpasswortes hat doch

nun wirklich gar nichts mit den Features zu tun. Des weiteren sind es unter anderem die Features, die den SQL-Server interessant machen. Außerdem ist der SQL-Server mit Sicherheit alles andere als ein Produkt für die Massen.

Dass man von Oracle nichts hört liegt erstens am Verbreitungsgrad, zweitens am Einsatzbereich und drittens daran, dass alle Microsoft, keiner aber Oracle anpinkeln will.

SQL-Injection ist grundsätzlich mit JEDER Datenbank möglich -- denn das Problem liegt, abgesehen von der Konfiguration der Datanbank, in der Programmierung der Clientsoftware. Das "advanced", wie es in dem PDF beschrieben wurde, basiert auf SQL-Server-Features. Wer nun denkt, Oracle oder DB2 würden solche Features nicht besitzen, ist ein Träumer. Ein solcher Artikel läßt sich für eine X-beliebige Datenbank schreiben, das Know-How vorrausgesetzt.

Grüße

Matze

p.s.: Standard wird mit d hinten geschrieben.

Nun stellt sich mir die Frage, ob ich ein "interessantes" Server-System oder ein sicheres Server-System haben möchte, wenn bestimmte Features erst eine solche Manipulation erleichtern?

Des Weiteren bezweilfe ich Deine Aussage über den Verbreitungsgrad von Oracle, jedenfalls in wissenschaftlich-technischen Bereichen, oder auch im eCommerce, sind die sehr weit verbreitet. Auch bietet Oracle mit seinem eigenen Dateisystem eine viel speziellere Rechtevergabe und somit spezielle Sicherheitsvorkehrungen.

Aber egal, das artet sonst immer mehr aus.

P.S.: Des Weiteren wird groß geschrieben, und im Absatz über Oracle gehört hinter 'hört' ein Komma.

Original geschrieben von bohni

Nun stellt sich mir die Frage, ob ich ein "interessantes" Server-System oder ein sicheres Server-System haben möchte, wenn bestimmte Features erst eine solche Manipulation erleichtern?

Dann schau dir die in dem Artikel genannten Features an. Durch eine richtige Konfiguration und korrekte Vergabe der Rechte hat sich das im Prinzip schon gegessen.

Des Weiteren bezweilfe ich Deine Aussage über den Verbreitungsgrad von Oracle, jedenfalls in wissenschaftlich-technischen Bereichen, oder auch im eCommerce, sind die sehr weit verbreitet.

Mag sein, aber gerade das Gespannt W2K/IIS/ASP/SQL-Server ist sehr verbreitet. Ich gehe jede Wette ein, dass mehr Webseiten mit SQL-Server statt Oracle herumlaufen. Meine LIste sollte ja nur ein Anhaltspunkt darstellen.

Auch bietet Oracle mit seinem eigenen Dateisystem eine viel speziellere Rechtevergabe und somit spezielle Sicherheitsvorkehrungen.

Als wenn ein Dateisystem einer Anwendung sicherer wäre als die des Systems darunter? Nun gut, ich verstehe von Oracle nicht allzuviel, zugegeben.

Aber egal, das artet sonst immer mehr aus.

Das Forum sollte mal ein Flame-Bereich einführen

P.S.: Des Weiteren wird groß geschrieben, und im Absatz über Oracle gehört hinter 'hört' ein Komma.

Du hast recht, aber solche Flüchtigkeitsfehler stören mich weitaus weniger, als die ewigen und leidigen Wiederholungen von "standart" oder "meißtens".

viele Grüße

Matze

oki-doki

Nur noch was zu Oracle: Oracle bietet bei der Installation an, das darunterliegende Dateisystem des Betriebssystems (meist UNIX) in ein Oracle-spezifisches Dateisystem umzuwandeln. Das geht jedoch nur, wenn dann dort ausschliesslich die Oracle-Datenbank läuft.