nicht angemeldet
utf-8 / db / magic_quotes - verständnis problem
tach mal wieder,
es geht mal wieder um ne Verständnisfrage.
Ich hab es mittlerweile geschaft mein db-skript, auch unter typo3, auf utf-8 umszustellen.
Ich hätte jetzt trotzdem erwartet, dass wenn ich jetzt strings mit anführungszeichen " oder ' in die datebank schreibe das mein query dadurch "zerstört" wird.
OK, magic_quotes_gpc ist eingeschaltet (magic_quotes_runtime nicht ?!?!), und in der DB sind auch die einzelnen anführungszeichen sauber drin.
Wie muss ich mir das vorstellen:
ändert magic_quotes die quotes um für den query und werden die dann wieder "zurückgewandelt".
oder sorgt die Kodierung von utf-8 dafür, dass die string-quotes nicht als query-quotes interpretiert werden?
Ich hoffe ihr versteht was ich meine.
gruss
caya
-
Ich hab es mittlerweile geschaft mein db-skript, auch unter typo3, auf utf-8 umszustellen.
Fein.
Ich hätte jetzt trotzdem erwartet, dass wenn ich jetzt strings mit anführungszeichen " oder ' in die datebank schreibe das mein query dadurch "zerstört" wird.
Das ist eine gute Erwartungshaltung.
OK, magic_quotes_gpc ist eingeschaltet (magic_quotes_runtime nicht ?!?!), und in der DB sind auch die einzelnen anführungszeichen sauber drin.
magic_quotes_gpc rettet dich halbwegs, aber nicht vollständig!
Wie muss ich mir das vorstellen:
ändert magic_quotes die quotes um für den query und werden die dann wieder "zurückgewandelt".
oder sorgt die Kodierung von utf-8 dafür, dass die string-quotes nicht als query-quotes interpretiert werden?Escaping ist allgemein eine Technik, die bewirkt: "Hallo, System[1], hier ist ein Escaping-Zeichen, und das darauf folgende Zeichen nimmst du bitte exakt so, wie es da steht, und nicht mit der sonst üblichen Sonderbedeutung[2]".
[1] Unter System ist alles mögliche zu verstehen: Die Kommandozeile, HTML-Ausgabe im Browser, oder eben ein SQL-Interpreter.
[2] Sonderbedeutung ist auch erstmal alles mögliche. Typisch ist, wie z.B. in MySQL: Das Zeichen ' begrenzt einen String.
Das Escaping-Zeichen wird beim Parsen des Gesamtbefehls eliminiert. Denn das Parsen bewirkt, dass Befehle in Programmaktionen und Strings eben in Strings umgesetzt und verarbeitet werden. Ein String im Speicher hat aber außenherum keine Stringbegrenzer mehr, und in sich selbst keine Escaping-Zeichen. Also landet ein escapter String pur in der Datenbank, und kommt auch pur wieder heraus.
Konkret zu PHP: Magic_quotes_gpc wirkt auf alles, was per GET, POST oder COOKIES hereinkommt, dort aber leider nur auf einige wenige Zeichen (die, die typischerweise störend wirken in den meisten Anwendungen).
Dummerweise werden dadurch nicht alle Zeichen entschärft, die in MySQL schädlich wirken können. Deshalb ist es eine gute Idee, wenn du magic_quotes_gpc abschaltest (oder prüfst, ob es eingeschaltet ist, und nur dann stripslashes() auf den String anwendest) und das Escaping für die Datenbank immer mit mysql_real_escape_string() erledigst. Das ist absolut sicher. Außerdem berücksichtigt die MySQL-Funktion den von dir gewählten Zeichensatz - das magic_quotes_gpc nicht. Das macht bei UTF-8 keinen Unterschied im Ergebnis von mysql_real_escape_string(), aber bei anderen Codierungen, insbesondere asiatischen, sehr wohl.
-
tach nochmal,
Fein.
:-)
Das ist eine gute Erwartungshaltung.
langjährige erfahrung in diesem forum
Dummerweise werden dadurch nicht alle Zeichen entschärft, die in MySQL schädlich wirken können.
das wären zum beispiel welche ?
Deshalb ist es eine gute Idee, wenn du magic_quotes_gpc abschaltest (oder prüfst, ob es eingeschaltet ist, und nur dann stripslashes() auf den String anwendest) und das Escaping für die Datenbank immer mit mysql_real_escape_string() erledigst. Das ist absolut sicher.
ok .. d.h. ich can mysql_real_escape_string() nicht auf ein magic_quotes geparsten string anwenden, da dann nochmal die bereits escapten Zeichen escaped werden (soviel zum thema eindeutschung) ...
lieg ich da richtig ??gruss
caya-
Hallo caya,
ok .. d.h. ich can mysql_real_escape_string() nicht auf ein magic_quotes geparsten string anwenden, da dann nochmal die bereits escapten Zeichen escaped werden (soviel zum thema eindeutschung) ...
lieg ich da richtig ??Ja. Magic Quotes sollten allerdings überhaupt nicht mehr verwendet werden, wenn du sie nicht in der Konfiguration abschalten kannst, kannst du sie mit stripslashes() unschädlich machen. Du solltest lediglich vorher mit ini_get() überprüfen, ob sie überhaupt aktiviert sind, da du dir ansonsten möglicherweise die Eingaben zerschiest.
In PHP 6 wird es Magic Quotes übrigens gar nicht mehr geben.
Schöne Grüße,
Johannes
-
tach nochmal nochmal ,
also um noch das letzte verständnis und die argumentation zu bekommen:
magic_quotes sind zu vermeiden oder zu umgehen weil:
-
diese funktion nicht alle character escaped welche vielleicht escaped werden sollten (unvollständigkeit)
-
der programmierer keinen zugriff drauf hat welche character es escaped etc. (unsicherheit)
-
es geeignetere funktionen gibt z.B. speziell auf mysql zugeschnittene mysql_real_escape_string (unzureichend)
hab ich was vergessen oder falsch beschrieben?
gruss
caya-
hi,
magic_quotes sind zu vermeiden oder zu umgehen weil:
- diese funktion nicht alle character escaped welche vielleicht escaped werden sollten (unvollständigkeit)
Ja.
- der programmierer keinen zugriff drauf hat welche character es escaped etc. (unsicherheit)
Doch, das ist eigentlich definiert.
- es geeignetere funktionen gibt z.B. speziell auf mysql zugeschnittene mysql_real_escape_string (unzureichend)
Ja.
hab ich was vergessen oder falsch beschrieben?
- Es zu Nachlässigkeiten führt.
Du entwickelst auf einem System mit magigc_quotes_gpc auf "on",
es "funzt" alles, auch bei Datenbankübergaben etc. - und dann soll das Script
irgendwann auch auf einem Server laufen, wo die Einstellung auf "off" ist - Bumm.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
- Es zu Nachlässigkeiten führt.
Du entwickelst auf einem System mit magigc_quotes_gpc auf "on",
es "funzt" alles, auch bei Datenbankübergaben etc. - und dann soll das Script
irgendwann auch auf einem Server laufen, wo die Einstellung auf "off" ist - Bumm.
Schlimmer noch: Normale Parameter, die man im Skript hat, funktionieren prächtig - aber sobald die Nutzer dann "kritische" Werte eingeben, bei denen Zeichen eigentlich zu escapen wären, knallt es. Man bemerkt also das Problem möglicherweise erst, wenn es zu spät ist.
- Es zu Nachlässigkeiten führt.
-
Hallo Caya,
hab ich was vergessen oder falsch beschrieben?
- Die Funktion wird in der Zukunft entfernt, du kannst also davon ausgehen, dass Scripte, die auf Magic Quotes setzen auf jeden Fall nicht unter PHP 6 laufen werden.
Schöne Grüße,
Johannes
-
magic_quotes sind zu vermeiden oder zu umgehen weil:
- diese funktion nicht alle character escaped welche vielleicht escaped werden sollten (unvollständigkeit)
Das ist so nicht richtig. Magic_quotes_gpc() wendet die Funktion addslashes() an, und diese Funktion escaped halt gewisse Zeichen. Wenn man nur genau diese Zeichen berücksichtigen will, ist das voll ok, aber addslashes() ist eben nur eine recht unspezifische Funktion.
- der programmierer keinen zugriff drauf hat welche character es escaped etc. (unsicherheit)
Doch, die Zeichen, die addslashes() entschärft, sind wohlbekannt.
- es geeignetere funktionen gibt z.B. speziell auf mysql zugeschnittene mysql_real_escape_string (unzureichend)
Das ist der einzige Punkt. addslashes() berücksichtigt einfach nicht alle notwendigen Zeichen. Für ein Escaping, das nicht vollständig ist, ist sowas tödlich.
Denk dir einfach einen Eimer, der auf halber Höhe ein Loch hat. Zum Transport von Wasser ist er nicht vollkommen ungeeignet - solange du nur die Menge transportieren willst, die in den halben Eimer reingeht, klappt alles. Aber wehe, du tust mehr Wasser rein, ohne das Loch zu berücksichtigen.
-
-
-
-