SQL-Injection trotzt Magic Quotes, wie ist das möglich?

[goodlike]

Ich habe jetzt öfters gelesen das Magic Quotes keinen ausreichenden Schutz gegen SQL-Injections bieten bzw. unsicher sind. Aber ich verstehe einfach nicht warum, schliesslich macht mysql_real_escape_string() auch nichts anderes?

Als Beispiel:

SELECT * FROM tablename
WHERE email='$x'; 

wenn der Benutzer jetzt die folgende Injektion macht:

$x(Hochkomma) OR 1=1 -- 

würde die Query folgendermaßen aussehen:

SELECT * FROM tablename
WHERE email='\' OR 1=1 --'; 

Das Backslash wird ohne Probleme mit Magic Quotes hinzugefügt und die potenzielle Injektion eliminiert. Wie kann es trotzdem möglich sein, dass die Magic Quotes gebypassed werden können?

[h3ll]

schliesslich macht mysql_real_escape_string() auch nichts anderes?

Doch, macht es:

Chris Shiflett: addslashes() Versus mysql_real_escape_string()

[goodlike]

Doch, macht es:

Chris Shiflett: addslashes() Versus mysql_real_escape_string()

Das heisst also, das Magic Quotes die interne Core-Funktion addslashes() benutzt?

Der Blogeintrag ist von Jan. 2006 und bezieht sich nicht auf UTF8 oder ISO8859-1, ich gehe stark davon aus, dass diese Art der Lücke mittlerweile schon längst gepatcht ist.

[wahsaga]

Das heisst also, das Magic Quotes die interne Core-Funktion addslashes() benutzt?

Nein, das wird sicher keine PHP-Funktion aufrufen - höchstens intern den gleichen C-Code.

Der Blogeintrag ist von Jan. 2006 und bezieht sich nicht auf UTF8 oder ISO8859-1, ich gehe stark davon aus, dass diese Art der Lücke mittlerweile schon längst gepatcht ist.

Ist ehrlich gesagt vollkommen egal, wo von du ausgehst ...

Es gibt eine Funktion, die explizit für das Absichern von Daten vor dem Einfügen in eine MySQL-Query gedacht ist. Die benutzt man, und fertig. Diskussionen darüber, ob theoretisch nicht auch irgendwas anderes reichen könnte oder nicht, sind dann vollkommen überflüssig.

(Und deshalb: *close* Bevor dieser Unsinn sonst wieder andere Neulinge verwirrt, die diesen Thread lesen.)