Sichere SQL Abfrage - SQL Injektion

Selbstverständlich schützt Drupal vor SQL Injektion.
Siehe dazu http://api.drupal.org/api/search/6/db_escape_string und auch hier http://api.drupal.org/api/drupal/includes--database.inc/group/database/6

musst man diese Funktion (db_escape_string($text)) selber bei einer SQL-Abfrage einbauen,
oder wird sie automatisch von z.B db_result() oder db_query() eingebunden?

danke

In _db_query_callback(), welche von db_query aufgerufen wird, gibt es ein spezielles Handling aller übergebenen Parameter mit db_escape_string() für Stings und intval() für Integer usw.

Und was ist, wenn db_query() so aufgerufen wird:
db_query("SELECT * FROM user WHERE name = "$myname");
wobei $myname vielleicht sogar von $_POST['myname'] stammt????

Es kann doch leicht sein, dass viele das so verwenden.
Dann gibt es KEINEN Schutz vor SQL-Injections?

Wenn Du bei eigenen Programmen so vorgehst, hast Du die Schutzmöglichkeiten verschenkt, aber das liegt nicht an Drupal, sondern an Dir. Du bist bei eigenen Modulen selbst dafür verantwortlich, daß Du "richtig" arbeitest.
Es gibt bei Drupal Programmier-Richtlinien in denen das Vorgehen bei DB-Abfragen etc. genau vorgegeben wird. Du wirst auf drupal.org kein Projekt einstellen dürfen, das nicht den Mindestvoraussetzungen genügt.

Beste Grüße
Werner

Ja klar.
Es geht aber weniger um das Programmieren von Modulen, sondern einfach um das Erweitern (z. Bsp. in tpl.php Dateien usw).

Ich wundere mich nur, dass das Thema "SQL Injection" hier im gesamten Drupalcenter nur in einem einzigen Thread so richtig vorkommen (also hier).

Ich glaub nicht, dass beinahe alle Programmierer die Anweisung
1) db_query("SELECT * FROM user WHERE name = '$myname' ...")

in dieser Form schreiben
2) db_query("SELECT * FROM user WHERE name ='%s' ....", $myname)

Naja, da man beim normalen Programmieren (nicht für Drupal) auch die Schreibweise 1) benutzen kann, wenn man vorher mysql_real_escape_string() über $myname ausführt (wenn es sich um Formularwerte handelt), ist man halt diese Schreibweise gewohnt und es wird daher sichert oft vorkommen, dass zumindest einige Programmiere die Schreibweise 1) benutzen.

Das öde an dieser Sache ist halt immer, dass hier überhaupt KEINE Fehlermeldung, kein Hinweise usw. kommt.
Es ist ja toll, dass diese Sicherheit in die Funktion db_query eingebaut ist, aber bei Variante 1) doch anscheinend nicht. Also eine gefährliche Sicherheit,....

Aber grundsätzlich scheinen diese SQL-Injections nicht so gefährlich zu sein.
Derzeit sind ja noch auf vielen Webserver "magic quotes" aktiviert.
Leider wird es dann ab PHP5.4 doch etwas gefährlicher, weil es dann wie es aussieht keine magic quotes mehr gibt.

Und da geht es weniger darum, dass es Programmierer gibt, die die Coderichtlinien nicht einhalten, sondern eher DARUM:
Jedem Programmierer kann es in der Hektik doch bei hunderten oder tausenden Codezeilen passieren, dass er einmal eine Schreibweise 1) statt 2) wählt .... Wer behauptet, das würde ihn niemals (also 100%) passieren, der behauptet fehlerfrei zu sein. Aber so ein Fehler kann jedem mal passieren ...

Und genau für diese Fehler, wo man halt mal nicht darauf geachtet hat, war "magic quotes" (falls aktiviert) eine gute Sache ... weil ein zusätzlicher Schutz für diese wenigen Fälle, wo man sich halt vertan hat!!!

Alles, was an den original PHP-Files von Drupal ändert, ist für mich Programmierung. Wer programmiert ist für das Ergebnis selbst verantwortlich. Sorry, wenn ich das so hart formuliere.
In der Dokumentation zur Dupal-API, auch bei den Datenbankfunktionen, wird auf die "ordentliche" Programmierung ausdrücklich hingewiesen. Ich kann niemand aus der Pflicht nehmen, sich danach zu richten.
db_query ist eine Funktion, die einen oder mehrere Parameter haben kann. Nur wenn ich die dadurch entstehenden Möglichkeiten richtig nutze erzeuge validen Code. Flüchtigkeit ist da für mich keine Ausrede.

Beste Grüße
Werner

Wie gesagt, es wird vielen Programmierern passieren, das eine oder andere Mal die obige Codezeile so wie in 1) zu schreiben statt wie in 2).

Und richtig zum Problem werden diese kleinen Fehlerchen erst ab PHP5.4, wenn magic quotes ausläuft.

Da aber niemand von SQL Injection - Hack-Angriffen berichtet, wird das wohl nicht so oft vorkommen, dass auf diese Weise gehackt wird ...