SQLs absichern

[Codewalker]

Hallo zusammen.

Ich habe durch einige Thread in der DP mittlerweile gelernt, dass Statements mit Parametern sicherer sind als per Format-Funktion. Trotzdem blieben zwei Fragen unbeantwortet:

1. Was genau sind prepared-Statements und was bringt mir das ganze? geklärt
2. Wo bringe ich die SQL-Strings im Programm unter, damit man möglichst nicht oder möglichst schwer daran rummanipulieren kann? Als normaler String (z.B. Query.SQL.Text := 'Hier das SQL'), als Konstante, als Ressourcenstring, etc.

[Bernhard Geyer]

Lies dir mal folgende Wiki-Einträge durch:

SQL-Injection
Prepared Statements

[jfheins]

zu 1.: Mit prepared-Statements erzählst du der Datenbank erstmal, was passieren soll mit Platzhaltern und lieferst die Daten anch. Die Daten können also nicht mehr den Ablauf verändern (was ja die Gefahr von Injections ist) weil der Ablauf (was eigentlich gemacht werden soll) schon feststeht, wenn die Daten ins Spiuel kommen.

zu 2.: vergebliche Liebesmühe. Wenn jemand unbedingt an der Datenbank herummanipulieren will, und deine Anwendung hat, musst du davon ausgehen, dass er sie nach belieben verändern könnte.
Dieses ganze absichern ist vor allem wichtig gegen Fehleingaben (absichlich oder unabsichtlich) und bei serverseitigen Systemen (aka Website) wo der User sogar als Angreifer betrachtet werden muss. Eine Sicherung gegen unbefugtes manipulieren sollte sowiso vorhanden sein. (gesichertes LAN oder Zugangsdaten zur Datenbank)

[Codewalker]

Okay, das mit den Prepared-Statements hat sich soweit geklärt und ist ja höchst sinnvoll.

Zitat:

Zitat von jfheins

vergebliche Liebesmühe. Wenn jemand unbedingt an der Datenbank herummanipulieren will, und deine Anwendung hat, musst du davon ausgehen, dass er sie nach belieben verändern könnte.

Verhindern kann ich es nicht, das ist mir klar. Ich will die Hürde aber schon ein wenig höher legen, um es nicht zu einfach zu machen. Das ganze ist eine lokale Firebird-DB, so dass Absicherung von Webserver, etc. entfällt.

[Bernhard Geyer]

zu 2:

Ein kleiner Schutz ist das du der Exe eine gültige Digitale Signatur verpasst um beim Programmstart diese Prüft.
Jeder gute Hacker kann das zwar aushebeln, aber gegenüber den "unbedarften Anwender" reicht das.

[Codewalker]

Okay, das signieren sollte ja gehen (testweise lokal). Wie kann ich denn programmseitig prüfen, ob die Datei noch signiert ist?

Edit: Schon was gefunden. http://www.delphipraxis.net/internal...ct.php?t=48444
Danke Euch beiden, ich werde das mal in Angriff nehmen und schauen, wie gut es funktioniert

Edit2: Args, damit kriege ich ja nur gesagt, ob überhaupt ein Zertifikat drin ist, dem vertraut wird und nicht, ob es auch wirklich mein eigenes noch ist. Hmpf, da werde ich wohl doch noch etwas mehr basteln müssen

[nahpets]

Hallo,

zum Programmabsichern:

Habe mir mal eine Routine gebaut, die eine CRC-Prüfsumme berechnet und an die Exe hängt. Diese Summe wird beim Programmstart überprüft und wenn sie nicht mit der gespeicherten übereinstimmt, startet das Programm nicht, bzw. gibt eine Fehlermeldung aus und beendet sich dann. Bei der Prüfung der CRC-Summe muss halt die Stelle ausgespart bleiben, an der sich die gespeicherte CRC-Summe befindet, da sich die CRC-Summe des Programmes ja (theoretisch) durch das Einfügen ihrer selbst in das Programm wieder verändern würde. Wenn Du das Ganze mit einem Programm machst, das mit UPX gepackt wurde, dann kann auch keiner die in der kompilierten Exe gespeicherten Strings (in Deinem Fall SQL-Statements) ändern ohne das Programm zu entpacken. Das entpackte Programm läuft aber bereits, wegen der nicht mehr stimmenden CRC-Summe nicht mehr. Es muss also eine neue CRC-Summe für das veränderte und wieder gepackte Programm an die entsprechende Stelle der Exe gepackt werden, damit das Programm mit dem geänderten SQL wieder läuft. Ist theoretisch möglich, der Aufwand ist aber nicht unerheblich, da nicht nur die Stelle der CRC-Summe "gefunden" werden muss, sondern auch der Alghorhythmus, mit der die CRC-Summen berechnet wird.

Alternative: SQL's in eine Datenbanktabelle schreiben und erst bei Bedarf daraus lesen, die Parameter mit den entsprechenden Werten versehen und dann ausführen. Im Kompilat des Programmes sind dann keine SQL's zu finden, die ggfls. manipuliert werden könnten.
Nebeneffekt: Beim Ändern/Wechseln der Datenbank müssen nur die SQL's in der Datenbanktabelle geändert werden und nicht das Programm. Das Programm kann ggfls. sogar ohne Änderung gegen unterschiedliche Datenbanken laufen, bei denen sich die SQL-Syntax in mehr oder weniger großem Umfang unterscheidet (soll ja zuweilen schon mal vorkommen ;-)).

[mkinzler]

Oder Abfragen in SPs packen. Der Datenabnkbenutzer dann nur Rechte zur Ausführung dieser geben

[Codewalker]

Kann ich denn auf SPs mit einer normalen Query zugreifen oder müsste ich dann das halbe programm umschreiben?

[mkinzler]

Zitat:

Zitat von Codewalker

Kann ich denn auf SPs mit einer normalen Query zugreifen oder müsste ich dann das halbe programm umschreiben?

Ja.