AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken FireBird - Prepared Statement - SQL Injection

FireBird - Prepared Statement - SQL Injection

Ein Thema von fkerber · begonnen am 15. Jul 2009 · letzter Beitrag vom 16. Jul 2009
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#1

FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 20:47
Datenbank: Firebird • Version: 2
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
Frederic Kerber
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.167 Beiträge
 
Delphi 10.4 Sydney
 
#2

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 20:58
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#3

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:00
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
Frederic Kerber
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.850 Beiträge
 
Delphi 11 Alexandria
 
#4

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:06
Den Code in SPs verlagern
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#5

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:10
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
Frederic Kerber
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.167 Beiträge
 
Delphi 10.4 Sydney
 
#6

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:20
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.850 Beiträge
 
Delphi 11 Alexandria
 
#7

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:25
Zitat:
Performancetechnich ist auch nicht viel gewonnen wenn man mit prepared Statements arbeitet.
Das kommt aber auch auf die komplexität der Abfragen an
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.167 Beiträge
 
Delphi 10.4 Sydney
 
#8

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:41
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
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.850 Beiträge
 
Delphi 11 Alexandria
 
#9

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:44
Es ging mir nicht um den Queryplan, sondern um die Reduktion der Datenmenge bzw. Verlagerung von Logik vom Client zum Server
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#10

Re: FireBird - Prepared Statement - SQL Injection

  Alt 15. Jul 2009, 21:51
Hi!

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

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
Frederic Kerber
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz