![]() |
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:
Oder kann man jetzt hier immer noch irgendetwas "Böses" machen?
$sql = ibase_prepare($db, "SELECT id FROM user WHERE username=? AND passwd = ?");
$res = ibase_execute($sql, $_POST['username'], $_POST['passwd']); Grüße, Frederic |
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.
|
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 |
Re: FireBird - Prepared Statement - SQL Injection
Den Code in SPs verlagern
|
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 |
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
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
|
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 |
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
|
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
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 |
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
Re: FireBird - Prepared Statement - SQL Injection
Hallo,
Zitat:
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 |
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 |
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
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:
Durch das OR wird die eigentliche Passwort/User Abfrage aufgehoben.
SELECT id FROM user WHERE username= 'xx' AND passwd = 'XX' OR (username LIKE '%ADMIN%' AND passwd LIKE '%')
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:
Das hatte ich noch vergessen. :-(
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 Und in Deinem Programm so aufrufen
SQL-Code:
Gruß Hartmuth
SELECT ID FROM SP_LOGIN(USERNAME,PW)
|
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 |
Re: FireBird - Prepared Statement - SQL Injection
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:22 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