SQL Statement in php mit Variable

tennessee

tennessee

Linuxfan
Hallo zusammen,

hat jemand ne Idee warum das so nicht funktioniert? ?(

PHP:
$id=$_REQUEST['id'];
$sql = 'Select html_text FROM cms WHERE id = "'.$id.'" ';

Wenn Ich die id hart codiert reinschreibe klappts.
Irgendwie muss es wohl ein " ' Fehler sein so das die where Bedingung nicht funktioniert.

ID an sich wird über das Formular gefüllt da ein Schreibvorgang auch geht.

:hilfe2:
 
ich würd anders "anführungsstricheln":
Code:
[COLOR=#000000][COLOR=#0000bb]$sql [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#dd0000]"Select html_text FROM cms WHERE id = "'[/COLOR][COLOR=#0000bb]$id[/COLOR][COLOR=#dd0000]'"[/COLOR][COLOR=#007700];
[/COLOR][/COLOR]


Was kommt den fürn Fehler?
Die $id ist auch wirklich initialisiert?

 
Zuletzt bearbeitet:
Die Shell kann innerhalb von Singlequotes nichts "lesen", also interpretiert die Shell "'$id'" als "$id" und nicht als den Variableninhalt, wie gewünscht.
Lass die "'" weg.
 
Ersteinmal: Du hast dir da eine SQL-Injection-Lücke eingebaut. Verwende am besten mysql_real_escape_string() oder caste - da du hier ja nur einen Integer-Wert brauchst - nach int:
PHP:
$id = (int)$_REQUEST['id'];

Zu deinem Problem: Was für ein Fehler wird denn von MySQL ausgegeben? Du verkettest eigentlich korrekt... Allerdings würde ich zur besseren Unterscheidung MySQL-Befehle wie SELECT groß schreiben, das dürfte mit deinem Problem allerdings nichts zu tun haben.
Du kannst versuchen, $id innerhalb des SQL-Statements in einfache Anführungsstriche zu setzen:
PHP:
$sql = 'SELECT html_text FROM cms WHERE id = \''.$id.'\'';
Versuche auch einmal, die Anführungsstriche ganz wegzulassen, also:
PHP:
$sql = 'SELECT html_text FROM cms WHERE id = '.$id;

Grüße,

Tblue
 
Die Shell kann innerhalb von Singlequotes nichts "lesen", also interpretiert die Shell "'$id'" als "$id" und nicht als den Variableninhalt, wie gewünscht.
Lass die "'" weg.

Nette Antwort aber imRuby, PHP, Perl, ... Unterforum an falscher Stelle.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Ersteinmal: Du hast dir da eine SQL-Injection-Lücke eingebaut. Verwende am besten mysql_real_escape_string() oder caste - da du hier ja nur einen Integer-Wert brauchst - nach int:
PHP:
$id = (int)$_REQUEST['id'];

Oder benutze prepared Statements bei denen sich der Treiber ums Escapen kümmert, dann ist das sogar DB unabhängig. Warum nur weiss das immer keiner...
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Ach so, das Ursprungsproblem ist, dass in SQL Abfragen Singlequotes bneutzt werden müssen, du hast oben als Beispiel das hier konstruiert:
Code:
SELECT html_text FROM cms WHERE id = "000"
 
Zuletzt bearbeitet:
Oder benutze prepared Statements bei denen sich der Treiber ums Escapen kümmert, dann ist das sogar DB unabhängig. Warum nur weiss das immer keiner...
Stimmt, das ist auch eine Möglichkeit (ich kenne und verwende prepared Statements, allerdings erst seit kurzem, deswegen ist mir das nicht eingefallen. Notiere ich mir fürs nächste Mal ;)).
 
PHP:
$id=$_REQUEST['id'];
$sql = 'Select html_text FROM cms WHERE id = "'.$id.'" ';

PHP:
$id = $_POST['id'];
# oder
$id = $_GET['id']
# niemals $_REQUEST .. dann kann immer noch einer mit post oder get kommen und etwas verändern ;)
# immer genau angeben, wie die daten ankommen.

// Anfrage erstellen
$query = sprintf("SELECT html_text FROM cms WHERE id=%s", mysql_real_escape_string($id));

Code:
# abfrage bei zahlen
SELECT * FROM table WHERE id = 1;
# abfrage bei strings(zeichenketten)
SELECT * FROM table WHERE name = 'String';
 
Code:
# niemals $_REQUEST .. dann kann immer noch einer mit post oder get kommen und etwas verändern ;)
# immer genau angeben, wie die daten ankommen.

Und? Das ist nun wirklich kein Schutz. Wenn der Angreifer manipulieren will, macht das keinen Unterschied. Ob GET oder POST die Daten werden immer alle vom Client gesendet und können beliebig manipuliert werden.
 
Code:
# niemals $_REQUEST .. dann kann immer noch einer mit post oder get kommen und etwas verändern ;)
# immer genau angeben, wie die daten ankommen.

Und? Das ist nun wirklich kein Schutz. Wenn der Angreifer manipulieren will, macht das keinen Unterschied. Ob GET oder POST die Daten werden immer alle vom Client gesendet und können beliebig manipuliert werden.

jep .. aber der angreifer kann solange versuchen mit get was zu drehen, wenn nur post benutzt wird und dementsprechend auch der source-code geschrieben wurde ;)

http://de.php.net/manual/de/reserved.variables.request.php schrieb:
Hinweis: Variablen, die dem Skript mittels der GET-, POST- und COOKIE-Inputmechanismen zur Verfügung gestellt werden. Der Inhalt ist nicht vertrauenswürdig. Das Vorhandensein und die Reihenfolge des Variableninhalts in diesem Array wird entsprechend der PHP-Konfigurationsdirektive variables_order bestimmt.

UCN:
Don't forget, because $_REQUEST is a different variable than $_GET and $_POST, it is treated as such in PHP -- modifying $_GET or $_POST elements at runtime will not affect the ellements in $_REQUEST, nor vice versa.
 
Naja, ich seh da eben weiterhin keinen Sinn drin. Das Ziel muss sein sichere Software zu entwickeln. Maßnahmen, die die Tragweite von übersehenen Fehlern effektiv reduzieren mögen da auch ok sein, aber das hier ist ein so minimaler Effekt, dass ich glaub ich der Bequemlichkeit halber bei $_REQUEST bliebe. Wer weiß ob ich das später sogar mal nutzbringend verwenden kann.
 

Ähnliche Themen

Tabelle aus SQL-Statement filtern

PostgreSQL und Spaltenalias

dovecot.sieve und spamassassin

CMS Problem [php]

SQL Select-Befehle mit PHP zu MS SQL Server via unixODBC und freeTDS

Zurück
Oben