Hallo dedlfix,

nein, das letzte ' in der FM dürfte aus seinem ursprünglichen SQL stammen.

Sowas in dieser Art:

$id = addslashes($_GET['ID']);
$sql = "SELECT foo FROM bar WHERE id='$id'";
//                                       ^ dieses hier

Beide Funktionen arbeiten nur dann wirksam, wenn man im Stringkontext ist.

Dass tabelle_id ein int ist und kein char/varchar, wäre anzunehmen. Aber sicher wissen wir das nicht. MYSQL hat sich ja das Type Juggling bei PHP abgeguckt und errät nach bestem Wissen und Gefühl die User-Absichten. Gelegentlicher Zehenverlust bei Schüssen in den Fuß nicht ausgeschlossen. Dann doch lieber ein ehrlicher Type Mismatch Error.

Wenn's eine INT Column ist, hast Du recht. Wenn man einen Integerwert erwartet, prüft man nicht auf einen String. Dann nimmt man intval() und schaltet eventuell eine /\d+/ Regex vor.

Empfohlen wird manchmal auch die filter_input-Funktion mit FILTER_VALIDATE_INT. Ich selbst mag die filter-Funktionen nicht so, weil die die Seuche mit führenden Nullen und Oktalzahlen haben.

Rolf

Tach!

Es bleibt sich also gleich, ob man die notwendigen Backslash- und Quote-Zeichen mit mysqli_real_escape_string(), mit addslashes() oder einer beliebigen anderen Funktion maskieren lässt.

Bis in einer zukünftigen MySQL-Version weitere Zeichen dazukommen, die von addSlashes nicht erfaßt werden.

Das halte ich für äußerst unwahrscheinlich, dass ein weiteres Zeichen zum Quotieren von Strings hinzukommen wird, welches man dann maskieren müsste. Zudem ändern weitere Zeichen am grundsätzlichen Problem nichts.

Verwendet man gleich die dafür vorgesehene Funktion mysqli_real_esacpe_string statt einer, die derzeit zufällig fast das gleiche macht, ist man auf der sicheren Seite.

Nein, nicht die Funktion ist entscheidend, sondern ihre korrekte Anwendung. Das sollte man nun langsam erkannt haben. addslashes() behandelt alle für das Quotieren notwendigen Zeichen. Wenn sie falsch angewendet wurde - was hier der Fall zu sein scheint - nützt es nichts, sie gegen eine anderen Funktion auszutauschen, die auf gleiche Weise falsch angewendet wird.

Es wäre nun schön, wenn wir nicht nur Indizien sehen (fertiges Statement mit SQL-Injection plus Fehlermeldung, bei der ein in der Injection steckendes GROUP BY ein Problem verursacht), sondern auch den Code, der das Statement zusammenbaut.

dedlfix.

Tach!

Es bleibt sich also gleich, ob man die notwendigen Backslash- und Quote-Zeichen mit mysqli_real_escape_string(), mit addslashes() oder einer beliebigen anderen Funktion maskieren lässt.

Bis in einer zukünftigen MySQL-Version weitere Zeichen dazukommen, die von addSlashes nicht erfaßt werden.

Wer gibt denn eine Garantie, dass mysql(i)_real_escape_string()^[1] die Funktion ist, die in der Zukunft den (unwahrscheinlichen) Fall abdeckt, hinzukommende für SQL-Injection relevante Zeichen oder andere Umstände zu berücksichtigen?

Verwendet man gleich die dafür vorgesehene Funktion mysqli_real_esacpe_string statt einer, die derzeit zufällig fast das gleiche macht, ist man auf der sicheren Seite.

mysql_escape_string() wurde mit PHP 4.1 eingeführt. Davor gab es nur addslashes() (Magic Quotes ignorieren wir mal). Damals hieß es schon, dass man von addslashes() auf die mysql-eigene Funktion umsteigen solle. Aber war das zukunftssicher? Jedenfalls kam mit PHP 4.3 dann mysql_real_escape_string() dazu, weil die Funktion zwar die notwendigen Zeichen (plus Zusatzzeichen \n, \r, ^Z) behandelt hatte, aber nicht berücksichtigt hatte, dass es Zeichenkodierungen abseits von ASCII-basierenden gibt, bei denen die Funktion versagte. Man hat sie nicht gändert, sondern die neue Funktion mysql_real_escape_string() dazugegeben. Die alte Funktion wurde nicht erweitert, weil sie wegen eines neuen Pflichtparameters nicht kompatibel war.

Aus der Geschichte kann man schlecht auf die Zukunft schließen ... aber ... es gibt bereits einen Nachfolger in der MySQL-Client-API, mit dem Namen mysql_real_escape_string_quote(). Man hat eine Situation gefunden hat, in der mysql_real_escape_string() nicht ausreicht. Die neue Funktion benötigt einen zusätzlichen Parameter, weswegen die alte Funktion nicht abwärtskompatibel weiterverwendet werden kann. In PHP ist die Funktion noch nicht angekommen. Mit der Aussage, mysql(i)_real_escape_string() sei zukunftssicher, würde ich mich jedenfalls schwertun.

dedlfix.

Hallo Der,

eher aus dem Nordosten...

ich musste tatsächlich einen Moment über diesen Satz nachdenken.

Zu Recht. Denn er war idiotisch.

Microsoft ist schließlich im Nordwesten. Im Nordosten findet man IBM. Und die Apache Foundation, in Wakefield, MA.

Rolf, Dussel!

Rolf

Tach!

Im Rahmen von URL Rewriting kann man in einer RewriteCond auf Teile der Request URL eingehen. Aber der Query-String ist da meines Wissens außen vor.

RewriteCond ist der Teil des Rewrite-Mechanismus, der Teile jenseits des Pfades berücksichtigen kann, darunter auch den %{QUERY_STRING}. Die RewriteRule kann hingegen nur den Pfad auswerten.

Es gibt auch noch RewriteMap, aber das muss mindestens im VHost konfiguriert werden, ist also oft nicht verwendbar. Damit kann man auch selbst geschriebene Programme laufen lassen und individuelle Umschreibungen vornehmen. Die Dokumentation schweigt sich aber darüber aus, ob nur der Pfad oder die komplette URL übergeben wird.

Generell würde ich das aber mit Vorsicht genießen, denn wenn man die Prüfung zum Apachen hin verlagert, man hat die Programmlogik an zwei Stellen zu beachten.

dedlfix.