Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   FireBird - Prepared Statement - SQL Injection (https://www.delphipraxis.net/137182-firebird-prepared-statement-sql-injection.html)

fkerber 15. Jul 2009 20:47

Datenbank: Firebird • Version: 2

FireBird - Prepared Statement - SQL Injection
 
Hi!

Das Ganze ist jetzt vom Quelltext her PHP, aber ich denke, es ist allgemein genug, dass man es trotzdem hier schreiben kann ;)

Ist folgendes "Vorgehen" sicher bzg. SQL Injections?
Code:
$sql = ibase_prepare($db, "SELECT id FROM user WHERE username=? AND passwd = ?");
$res = ibase_execute($sql, $_POST['username'], $_POST['passwd']);
Oder kann man jetzt hier immer noch irgendetwas "Böses" machen?


Grüße, Frederic

Bernhard Geyer 15. Jul 2009 20:58

Re: FireBird - Prepared Statement - SQL Injection
 
Prepared Statements sind sicher - außer es liegt ein Fehler im SQL-Parser der Datenbank vor. Bei solch einem ist aber der Hersteller des DBMS am zug.

fkerber 15. Jul 2009 21:00

Re: FireBird - Prepared Statement - SQL Injection
 
Gut, das ist bei FB hoffentlich nicht zu erwarten.

Oder gibt es noch einen sichereren Weg, der auch für sowas noch sicher wäre?


Grüße, Frederic

mkinzler 15. Jul 2009 21:06

Re: FireBird - Prepared Statement - SQL Injection
 
Den Code in SPs verlagern

fkerber 15. Jul 2009 21:10

Re: FireBird - Prepared Statement - SQL Injection
 
Inwiefern macht das die Sache sicherer? Und wie wäre das von der Performance her?
Wenn ich das richtig sehe, hätte ich dann eine SP, die Benutzername und Passwort erwartet und wahlweise die ID oder -1 zurückliefert?

Ist es lohnenswert, alle derartigen Abfragen in SPs auszulagern oder gibt es da auch Nachteile?


Grüße, Frederic

Bernhard Geyer 15. Jul 2009 21:20

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Zitat von fkerber
Ist es lohnenswert, alle derartigen Abfragen in SPs auszulagern oder gibt es da auch Nachteile?

Wenn man mehrere DBMS unterstützen wird ist es mit mehr Aufwand und Know-How verbunden (Jedes DMBS kocht ihr eigenes SP-Süppchen). Performancetechnich ist auch nicht viel gewonnen wenn man mit prepared Statements arbeitet.

mkinzler 15. Jul 2009 21:25

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Performancetechnich ist auch nicht viel gewonnen wenn man mit prepared Statements arbeitet.
Das kommt aber auch auf die komplexität der Abfragen an

Bernhard Geyer 15. Jul 2009 21:41

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Zitat von mkinzler
Zitat:

Performancetechnich ist auch nicht viel gewonnen wenn man mit prepared Statements arbeitet.
Das kommt aber auch auf die komplexität der Abfragen an

Wenn man sich noch selbst einen Cache der Prepared Statements anlegt braucht der Queryplan nur einmal währen der Programmlaufzeit erzeugt werden - und ist dann immer frisch :-)

mkinzler 15. Jul 2009 21:44

Re: FireBird - Prepared Statement - SQL Injection
 
Es ging mir nicht um den Queryplan, sondern um die Reduktion der Datenmenge bzw. Verlagerung von Logik vom Client zum Server

fkerber 15. Jul 2009 21:51

Re: FireBird - Prepared Statement - SQL Injection
 
Hi!

Ok, das ist schon zu viel für mich ;)
Kann man das auf einfacherem Niveau für mich erklären? :mrgreen:

Also:
SP besser, weil?
oder
Egal
oder
Prepared besser, weil?

Oder evtl. Umstände unter denen das eine besser ist als das andere.
Performance ist nicht unwichtig, da es viele gleichzeitige Zugriffe geben könnte, aber die einzelnen Zugriffe werden eher einfache Selects / Inserts etc sein werden...


Grüße, Frederic

mkinzler 15. Jul 2009 21:55

Re: FireBird - Prepared Statement - SQL Injection
 
In Stored Procedures kann man neben "normalem" SQL-Code auch Strukturierte Anweisungen ( IF..Then..Else, For usw.) verwenden. So kann man Programmlogik auf den Server verlagern

Bernhard Geyer 15. Jul 2009 22:04

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Zitat von mkinzler
Es ging mir nicht um den Queryplan, sondern um die Reduktion der Datenmenge bzw. Verlagerung von Logik vom Client zum Server

Das kann man auch duch ein 3 bzw. N-Tier Architektur. Und m.E. ist es besser sich nicht zu sehr auf DB-Eigenheiten einzulassen um den Vendor-Lockin nicht zu groß werden zu lassen. Und auch Programmupdates erfordern ohne SP's bei weiten seltener ein DB-Update (mit Problem entsprechend die DB kurzzeitig offline schalten zu müssen).

fkerber 15. Jul 2009 22:07

Re: FireBird - Prepared Statement - SQL Injection
 
Also kann ich da rauslesen, dass für ein Statement wie dem obigem die prepared-Sache am besten geeignet wäre?


Grüße, Frederic

mkinzler 16. Jul 2009 06:39

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Zitat von fkerber
Also kann ich da rauslesen, dass für ein Statement wie dem obigem die prepared-Sache am besten geeignet wäre?


Grüße, Frederic

Ja für einfache Abfragen sind SPs meiner Meinung nach oversized. Es gibt aber auch Programmiererer, die alles als SPs implementieren

borwin 16. Jul 2009 08:49

Re: FireBird - Prepared Statement - SQL Injection
 
Hallo,

Zitat:

Ist folgendes "Vorgehen" sicher bzg. SQL Injections?
So wie Du es vor hast sehe ich schon eine Möglichkeit. Wenn man mit ein bischen probieren folgendes eingibt könnte man sich
Userrechte eines Admins 'erschleichen'
Benutzername: 'xxx'
Password: "'XX' OR (username LIKE '%ADMIN%' AND passwd LIKE '%'"

Wenn man die Abfrage in eine SP legt, ist sowas nicht möglich.
Der Vorteil wäre auch noch, dass man weitere Verarbeitungen in die gleiche SP legen kann. z.B. Abspeichern der Anmeldung,
prüfen von SessionsID.
Ich habe für ein Webprojekt alles komplett in SP gelegt. Will ich jetzt von php auf z.B. ASP.net umsteigen muss ich die Verarbeitungslogig gegen die DB
nicht mehr migrieren.

Gruß Borwin

fkerber 16. Jul 2009 10:35

Re: FireBird - Prepared Statement - SQL Injection
 
Hi!

oO
Ich blicke bei den ganzen Anführungszeichen nicht so ganz durch - kannst du ein konkretes Beispiel ohne zusätzliche Anführungszeichen machen.

Also sagen wir, es gibt folgende Nutzer:Passwort-Kombis:

normalerNutzer:pass1
admin:pass2

Was müsste man jetzt als Benutzername und Passwort eingeben, um mit obigem Code sich unrechtmäßig als admin einloggen zu können?
Ich dachte, die prepared-Geschichte würde mich vor diesen Anführungszeichen-Spielereien schützen?



Grüße, Frederic

mkinzler 16. Jul 2009 10:42

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Ich dachte, die prepared-Geschichte würde mich vor diesen Anführungszeichen-Spielereien schützen?
Das ist auch ein einer der Gründe Parameter einzusetzen.

borwin 16. Jul 2009 11:45

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Ich blicke bei den ganzen Anführungszeichen nicht so ganz durch - kannst du ein konkretes Beispiel ohne zusätzliche Anführungszeichen machen.
In Deinem Feld für Benutzername würde ich nur dummy Werte eingeben z.B. xx
Beim Passwort genau diese Zeichenkette : 'XX' OR (username LIKE '%ADMIN%' AND passwd LIKE '%')
Die Hochkomma sind Notwendig, da er die gesamte Zeichenkette quasi als Passwort an das SQL anhängt. Damit würde Dein eigentliches
SQL veränder werden. Wenn Du es als String ausgebe lässt, sieht es dann so aus

SQL-Code:
SELECT id FROM user WHERE username= 'xx' AND passwd = 'XX' OR (username LIKE '%ADMIN%' AND passwd LIKE '%')
Durch das OR wird die eigentliche Passwort/User Abfrage aufgehoben.
Das SQL würde genau so an die Datenbank geschickt.

Mit prepared und Parameter solltes es so wie oben beschrieben eigentlich nicht mehr möglich sein. Da für kenne ich aber php zu wenig.
Wie gesagt ich würde immer eine SP vorziehen. Da bist Du auf der sicheren Seite.

Das Könnte dann so aussehen

SQL-Code:
CREATE PROCEDURE SP_LOGIN (
    USERNAME VARCHAR(40),
    PW VARCHAR(40))
RETURNS (
    ID INTEGER)
AS
BEGIN
  SELECT ID
  FROM USER
  WHERE username = :USERNAME
  AND passwd = :PW
  INTO :ID;
  SUSPEND;
END
Das hatte ich noch vergessen. :-(
Und in Deinem Programm so aufrufen

SQL-Code:
SELECT ID FROM SP_LOGIN(USERNAME,PW)
Gruß Hartmuth

fkerber 16. Jul 2009 12:34

Re: FireBird - Prepared Statement - SQL Injection
 
Hi!

Danke für dein Code-Beispiel.

Jetzt nochmal ganz konkret meine Frage:
Reicht die Verwendung eines prepared-Statements, um die ' und "-Spielereien auszuschalten oder ist die Verwendung einer SP notwendig?


Grüße, Frederic

Bernhard Geyer 16. Jul 2009 12:56

Re: FireBird - Prepared Statement - SQL Injection
 
Zitat:

Zitat von fkerber
Reicht die Verwendung eines prepared-Statements, um die ' und "-Spielereien auszuschalten oder ist die Verwendung einer SP notwendig?

Die verwendung von parametrisierten Abfragen reicht - egal ob du die nun preparst für Performanceverbesserung bei mehrfacher verwendung oder nicht.


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:50 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz