nicht angemeldet
Tach!
php.net schreibt:
Characters encoded are NUL (ASCII 0), \n, \r, , ', ", and Control-Z.
Die folgende Query erwartet einen numerischen Parameter (als PHP-String mit string parsing):
$sql = "select foo,bar from atable where key=$keyValue"Wenn ich es schaffe, hier statt bspw. 4711 den "Wert"
1 OR 1=1zu injizieren, hilft mir Escaping jeglicher Art nicht weiter.
Wenn du da Escaping versuchst, hast du das System nicht verstanden. Escaping ist kein magisches "Mach-es-in-jedem-Fall-sicher-Ding". Die Funktion bei MySQL heißt ja auch nicht umsonst _string am Ende.
Im Kontextwechsel-Artikel gibt es jedenfalls nicht umsonst einen eigenen Abschnitt für Zahlen.
Oder schlimmer noch:
1; DROP atable. Das Semikolon wird nicht escaped.
Mehr als ein Statement führt MySQL nicht aus, wenn man nicht Multi-Query händisch aktiviert hat.
Trotzdem ist SQL mit direkt eingesetzten Werten ein Kopfschmerzgenerator und daher würde ich dann, wenn zugelieferte Werte als Parameter zu nutzen sind, prepared statements immer vorziehen, auch wenn das einen zusätzlichen Roundtrip zum SQL Server bedeutet. Wenn man Hochlast-Sites baut, in denen das zum Problem werden kann, muss man ohnehin ganz andere Mechanismen zur Laststeuerung bzw. -reduktion einsetzen.
Wenn du dabei schon Kopfschmerzen bekommst, solltest du vielleicht nicht programmieren. Du kannst zwar im Falle SQLs mit Prepared Statements den Kontextwechsel und die Maskiernotwendigkeit umgehen, aber du brauchst das Prinzip noch zu jeder Menge anderer Gelegenheiten, für die es etwas vergleichbares nicht gibt. Du musst dich also weiterhin damit beschäftigen, an welcher Stelle welches Escaping notwendig ist. Wenn du das Prinzip verstanden hast, spielt es im Prinzip keine Rolle, ob du korrektes Escaping oder Prepared Statements verwendest.
dedlfix.
Rolf b
Matthias Scharwies
Auge