TQuery.open führt DDL-/DML-Anweisung aus

[thlicht]

Hallo zusammen,

mein erster Beitrag und ein wirklicher Hammer. Ich habe eine Anwendung (D5 Enterprise), die auf eine Oracle-XE-DB zugreift und aus einer Textdatei eine Query lädt und diese mit Open öffnet. Also ein einfaches Tool, um flexibel Auswertungen zu erstellen.

Wenn meine Textdatei nun Datenmanipluationen (DML) oder gar Datendefinitionen (DDL) enthält, werden diese auf dem Server ausgeführt, bevor Delhi mir in einer Fehlermeldung mitteilt, dass es keinen Cursor erzeugen konnte. Nicht gerade lustig, wenn in der Textdatei so was wie "drop table ..." steht. Die Auswertungen sollen vom Admin meines Kunden selbst erstellt werden, und so mancher Bastler könnte da auf dumme Ideen kommen.

Auch der Versuch, DB.Readonly:=true zu setzen, bringt keine Änderung.

Wie schaffe ich es, Änderungen an der Datenbank zu unterdrücken?

Danke

[mkinzler]

-Benutzerrechte beschränken (kein GRANT)
-Abfragen vorher parsen

[thlicht]

Das grundsätzlich Beschränken der Rechte ist nur schwer möglich, da die angemeldeten User an anderer Stelle natürlich Datenänderungen vornehmen dürfen. Ich hatte auch schon überlegt, das Abfragemodul unter einem besodneren User-Account laufen zu lassen und diesem die Rechte zu beschneiden. Ist aber etwas wenig elegant.

Parsen ist auch möglich, nur sind es eben doch eine ganze Menge Begriffe die auszufiltern sind. Wenn man das richtig macht, müsste man sogar den Context bewerten. Ich denke, wenn es keinen besseren Weg gibt, werde ich wohl diesen wählen.

Ich hatte aber gehofft, dass die BDE irgendwie eine Klassifikation des Befehls (z.B. beim Prepare) vornehmen kann (wäre dort natürlich auch sowas wie parsen) und mir diese stupide Arbeit abnimmt. Schaun wir mal ...

[mkinzler]

Ein TQuery kennt zwar die Eigenschaft .Prepare, ich versteh aber nicht ganz wie dir das bei deinem Problem helfen soll. Prepare überträgt zwar die Abfrage, bereitet sie vor und führt sie nicht gleich aus, aber wenn der Anwender "Drop ..." eingibt wird sie trotzdem ausgeführt.

BTW. Warum nimmst du die BDE für Oracle ?

[thlicht]

Ja, mit dem PREPARE das war nur eine Idee in der Hoffung, jemand nimmt mir die Arbeit einer Analyse der SQL-Anweisung ab. Der Vorschlag war nciht wirklich qualifiziert, gebe ich gerne zu. I

BDE nehme ich aus historischen Gründen. Die ersten Zeilen der Anwendung sind vor ca 10 Jahren entstanden. Bete von Windows-Version zu Version, dass die BDE noch läuft. Kennst Du eine Alternative, die eine wirklich fette Applikation mit vielen Querys und StoredProc mit vertretbarem Aufwand von BDE migrieren läßt (und vielleicht noch mein eigentliches aktuelles Problem lösen kann)?
Danke

[mkinzler]

Alle auf TDataSet basierenden Komponenten funktionieren ähnlich wie die BDE. Aber natürlich hast du immer einen Migrationsaufwand. Aber der Einsatz der BDE schränkt die Fähigkeiten neuer DBMS stark ein. Schon deswegen sollte man nach Alternativen Ausschau halten. Wie z.B. OCI, ZEOS, AnyDAC, ODAC, ADO, ...

[thlicht]

Ok, ich sehe, dass ich da wohl mit BDE nicht weiterkommen. Werde mir bei Gelegeheit mal die Alternative ansehen.
Dank dir für die schnelle Hilfe. Werde den Case schließen.

Gute nacht

[Bernhard Geyer]

Der Vorschlag von mkinzler ist schon der richtige: Du solltest den "normalen" Usern auf der DB kein DDL-Rechte geben. Eintrag/Löschen von Datensätzen sind wieder andere Rechte (DML) die du unabhängig davon einstellen kannst.

Wie schaut denn eine Textdatei aus? Ich vermute du kannst den Vorschlag mit alternativen Komponenten um dieses Problem zu lösen vergessen da du vermutlich ein gewaltiges Sicherheitloch im Bezug auf SQL-Injection besitzt.

[mkinzler]

Meine Vorschlag zum Kompo-Wechsel war auch unabhängig von diesem Problem zu verstehen, da sie es ja auch nicht lösen können, sondern auf Grund der Tatsache das mit der BDE ein Großteil der Fähigkeiten von Oracle halt nicht zur Verfügung stehen.

[mikhal]

Warum legst du nicht ein Schema auf deiner Oracle-Datenbank an, in dem ausschließlich Views angelegt werden (vom Admin oder anderen berechtigten Personen) und läßt in deiner Applikation nur den Select auf diese Views zu?

Ggf. mit einem kleinen Dialog zur Übergabe von Parametern.

Grüße
mikhal

[thlicht]

Hallo zusammen und vielen Dank für die vielen Anregungen, die noch in den letzten beiträgen auftauchten.

Also Hintergund des Problemes ist eine Anwednung, die es dem Admin des Systems ermöglichen soll, individuelle Auswertungen in SQL zu formulieren und als Textfile oder BLOB zu speichern. Anwender können dann diese Auswertungen in einem Dialog auswählen und ausführen (mit dem eingangs erwähnten OPEN). Dieses Admins, die die Abfragen erstellen, kennnen das Datenmodell und besitzen auch einen gültigen Account um Daten zu ändern (DML) oder zum Stukturen zu maipulieren (DDL). Aber ihr habt natürlich recht, das Beste ist ein konsequenter Zugriffsschutz über readonly-VIWEs. Mit dem Thema SQL-Injection muss ich mich gesondert befassen, das Problem hatte ich so noch gar nicht beachtet.

[hoika]

Hallo,

ich würde einfach prüfen, ob das erste Wort der Abfrage ein SELECT ist,
und wenn nicht, war es das.
Natürlich musst du aufpassen, dass er auch ein ' Select' machen könnte.

Heiko

[mkinzler]

Zitat:

Zitat von hoika

Hallo,

ich würde einfach prüfen, ob das erste Wort der Abfrage ein SELECT ist,
und wenn nicht, war es das.
Natürlich musst du aufpassen, dass er auch ein ' Select' machen könnte.

Heiko

Dann wäre es einfach nur den SELECT zu granten.

[thlicht]

Hallo zusammen,

die letzten beiden Tipps klingen interessant, denn real betrachtet kommen eh nur Admins in Frage, die Querries zu erstellen. Mit einem speziellen "Report"-User der nur ein SELECT ausführen darf wäre aus praktischer Sicht wohl die einfachste Lösung umsetzbar und Datenmanipulation weitegehend ausgeschlossen. Klasse Idee ...