(my)SQL und Bash - prepared Statements

[ckoepp]

Hallo zusammen,

ich bin dabei ein kleines simples Tool in bash zu schreiben und habe ein Problemchen dabei...

Das Script soll von der Datenbank Dinge abfragen die es durch ein simples WHERE eingrenzt. Leider ist es so, dass ich die WHERE Bedingung als Argument übergeben bekomme (so ist das eben mit postfix).

Jetzt bleibt die Frage: wie entschärfe ich die WHERE Bedingung so, dass nichts passieren kann. Klar, der Nutzer dem dem die Abfrage läuft darf eh nix reinschreiben sondern nur aus einer Tabelle lesen. Aber schön ist's trotzdem nicht...

Daher die Frage: gibt es eine Möglichkeit eine Art prepared Statements, wie man sie aus den Hochsprachen kennt, in bash umzusetzen? Ab mySQL 6.0 würde es glaub direkt auf dem Server gehen, aber so ganz das Wahre ist das ja nicht

Wie habt/würdet ihr das Problem lösen?

[Duff]

Ist die Datenbank denn so groß, dass eine "falsche" where-Klausel die Performance der DB so start beeinträchtigen kann?

Ansonsten eventuell überprüfen, ob in der where Klause bestimmte Felder der DB vorkommen...(nur so eine Idee)

[ckoepp]

Es geht da nicht um die Größe...

Was machst du denn wenn da jemand die Abfrage folgend abändert: "SELECT * FROM Test WHERE idXYZ = $1" wird zu "SELECT * FROM Test WHERE idXYZ = 1 OR 1=1; DELETE * FROM Test;" ?
Dazu reicht es aus dem Script meinScript.sh '1 OR 1=1; DELETE * FROM Test;' mitzugeben

Dadurch sind halt beliebige Injections möglich...

[Duff]

Stimmt, da hast du natürlich Recht!

Dann würde ich den Übergabe-String auf delete (Groß-/Kleinschreibung) überprüfen und sowas nicht zulassen.
Des Weiteren dürfen nur bestimmte Felder aus der Tabelle vorkommen und mit einem =-Zeichen versehen werden. Zudem würde ich noch Sachen wie order und group zulassen.

...schöne Aufgaben für sed und awk in bash...

[FitzeFatze]

Kannst du das nicht auf DB Ebene regeln? Also, dass du Befehle wie DELETE etc für den User sperrst, der das Script ausführt?


Ciao

[ckoepp]

Sicher, der User den das Script für's DBMS darf nur einen Select auf eine ganz bestimmte Tabelle machen.

Aber hätte ja sein können, dass jemand ne tollere Lösung anzubieten hätte. Jetzt ist das Script sicher, aber wer weiß wo es noch so alles eingesetzt wird - irgendwann wirds jemand ohne nachzudenken übernehmen und -uroot hinter das mysql-Cmd setzen

[schorsch_76]

Mach doch vor dem eigentlichen Statement eine Parameter Überprüfung. Nur wenn die Parameter ok sind, wird das Statement ausgeführt.

[ckoepp]

Dazu müsste ich ja den Inhalt der DB kennen

Das Problem ist folgendes: ich bekomm ne eMail Adresse rein. Da bleibt dann nur ein regExp...aber lieber wären mir eben so tolle Statements. Hab bis eben gesucht und nix gefunden - glaube dann wirds wohl oder übel über reguläre Ausdrücke laufen müssen. Nur wirklich sicher sind die halt auch nie

[goeb]

Also unter http://dev.mysql.com/doc/refman/5.0/en/ ... ments.html steht, daß serverseitige Prepared Statements in der 5.0 funktionieren...

MfG, gœb

[Sid Burn]

Wie bekommst du den die Parameter übergeben?
Die komplette WHERE Abfrage als einen String oder die Parameter einzelnd?

Ansonsten würde ich für sowas eher Perl nehmen. Dort kannst du dann Problemlos Prepared Statements erzeugen. Allerdiegns wenn die Übergabe schlecht ausschaut sieht es natülich etwas blöd aus. Wenn du einen dicken String bekommst ist es nahezu unmöglich das sauber hinzubekommen.

Ansonsten musst du doch auch Benutzernamen und PW angeben bei der Übergabe. Wenn du nur Lesen musst dann würde ich für den Benutzer auch dementsprechend alle Rechte entziehen das er DELETE, DROP, INSERT, UPDATE, ... ausführen darf. Und das dieser nur noch SELECT Statements ausführen darf.

[roli]

Hi,

du koenntest den uebergebenen String z.B. vor ausfuehrung auf ggf. enthaltene Semikolons scannen.

[Sid Burn]

Hi,
du koenntest den uebergebenen String z.B. vor ausfuehrung auf ggf. enthaltene Semikolons scannen.

Und dann?

Code: Alles auswählen

SELECT *
FROM   table
WHERE  text LIKE '%test; fall%'

[roli]

Hi,

ok, das ein Semikolon auch berechtigterweise in einer Abfrage sehen kann wie du hier zeigst hatte ich nicht bedacht. Dein Beispiel ist zwar richtig, keine Frage, aber jedenfalls aus meiner Sicht eher die Ausnahme. Von daher könnte man halt hingehen und das Semikolon "per Order by Mufti" den Usern einfach verbieten, es sei denn es gibt ein berechtigtes Interesse.
Am langen Ende ziehlt deine Frage in Richtung SQL-Injection. Such mal danach, oder schau die mal das "SQL Injection Cheat Sheet" auf http://ferruh.mavituna.com/tag/sql-injection/ an.

[Sid Burn]

Hi,
ok, das ein Semikolon auch berechtigterweise in einer Abfrage sehen kann wie du hier zeigst hatte ich nicht bedacht. Dein Beispiel ist zwar richtig, keine Frage, aber jedenfalls aus meiner Sicht eher die Ausnahme.

Spielt keine Rolle ob es aus deiner Sicht oft vorkommt oder nicht. Semikolions einfach so ausfiltern oder ähnliches ist nicht korrekt. Wenn auf einmal irgendwas nicht geht genau deswegen sitzt man ne ewigkeit davor und sucht den Fehler. Und so wie das Glück ist reicht es in 99,9999% der Fälle aus, und in einem Fall geht es nicht und man sitz davor und sucht das Problem.

Am langen Ende ziehlt deine Frage in Richtung SQL-Injection

Soweit sind wir schon seit der Thread ersteller diesen Thread gestartet hat. Deswegen fragte er ja nach Prepared Statements.

Mit Perl oder ähnliches (Ruby, Python, etc.) kann man schnell so ein Skript realisieren und ein Prepared Statement abschicken. Sofern nicht irgendeine ausrede existiert warum er es in Bash machen muss. Allerdiengs hängt es davon ab wie er die Parameter übergeben bekommt. Bekommt er einfach nur die komplette WHERE Klausel über einen Parameter geliefert kann er es eigentlich vergessen 100%ig sicher zu machen.

Aber der Thread ersteller Antwortet ja nicht mehr. Von daher scheint es nicht wichtig zu sein.