FireBird - Prepared Statement - SQL Injection

[fkerber]

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]

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]

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]

Den Code in SPs verlagern

[fkerber]

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]

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]

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]

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]

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

[fkerber]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.