nicht angemeldet
Hi!
So generell gesagt ist das nicht richtig, denn sie ist nur für Strings vorgesehen. Bei Zahlen, die nicht in Anführungszeichen in ein SQL-Statement geschrieben werden, ist diese Funktion nicht nur überflüssig, sie wiegt den Anwender auch in falscher Sicherheit. Siehe Zahlen im (My)SQL-Statement.
Ich setze meine Anführungszeichen eh selbst in der Abfrage. Werte die Zahlen sein müssen werden vorher darauf überprüft. Die bekommen dann keine Anführungszeichen was aber bei MySQL eh uninteressant ist, wenn ein Feld ein Integer erwartet wird es per Typecast umgewandelt.
Jo, genauso, wie ich es im verlinkten Absatz beschrieben habe. Du gibst mit deiner Antwort zu, dass du für Zahlenwerte Ausnahmen machst. Das ist richtig und gut so. Ich sprach diesen Punkt aber an, weil gelegentlich hier Postings auftauchen, die diese Zahlen-Ausnahme so nicht gesehen haben, und ich zunächst vermutet hatte, dass dir dieses Thema nicht bewusst war.
Hier mal die Funktion die bei meiner Datenbank-Klasse zum escapen da ist. Nicht unbedingt perfekt, aber naja:
Find ich auch. Schon nicht schlecht, aber wenn du gestattest:
public function escape($var)
{
if ( is_int($var) || is_bool($var) ) { return (int)$var; }
if ( is_float($var) ) { return (float)$var; }if( get_magic_quotes_gpc() )
{
$var = stripslashes($var);
}return mysql_real_escape_string($var, $this->db_connect_id);
}
Du scheinst davon auszugehen, dass du nur Werte behandeln musst, die über $\_GET, $\_POST und $\_COOKIE (GPC) reingekommen sind. Du behandelst nämlich den übergebenen Wert gegen Magic Quotes, die aber eben nur bei GPC-Variablen gesetzt sind. Du musst aber alle Werte berücksichtigen, die in ein SQL-Statement einfließen sollen, nicht nur GPC-Werte. Das mag in deinem Script, in dem du diese Funktion verwendest, vielleicht nicht der Fall sein, aber das macht diese Funktion weniger universell verwendbar. Die Magic-Quotes-Behandlung sollte bei einem nach EVA-Prinzip strukturierten Programmablauf im E(ingabe)-Teil angesiedelt sein. Du brauchst die MQ-Behandlung ja generell, nicht nur für Werte, die über SQL weitergereicht werden und von deiner Funktion behandelt werden sollen, sondern unter anderem auch für Werte, die nach HTML ausgegeben werden sollen (zum Beispiel beim Affenformular).
Du prüfst am Anfang auf int, bool und float. (Der Typecast nach float ist nicht nötig, denn is\_float() stellt ja schon sicher, dass $var von diesem Typ ist.) Du prüft also schon, ob du (Boolean und) Zahlentypen (nicht jedoch in Strings steckende Zahlenwerte) übergeben bekommst. Allerdings musst du beim Verwenden der Funktion ebenfalls aufpassen, ob du einen Zahlentyp(!) einfügst oder einen String, denn danach richtet sich ob du Anführungszeichen setzen musst oder nicht. Wenn du hingegen stets Anführungszeichen setzt, brauchst du diese Funktion nicht, denn dann erledigt mysql\_real\_escape\_string() allein schon alles (abgesehen von der MQ-Behandlung, aber die ist ja sowieso am Scriptanfang besser aufgehoben). Damit deine Funktion einen wirklichen Mehrwert hat, fehlt ihr zum Beispiel noch, dass sie automatisch Anführungszeichen hinzufügt, je nach Notwendigkeit. (Dann braucht sie aber auch noch einen anderen Namen, denn sie escapet dann nicht mehr nur sondern quotet auch.)
Was auch nicht hervorgeht, ist, wie du Zahlenwerte in GPC-Variablen behandelst, denn in GPC stehen generell Strings (wenn man sie nicht händisch typecastet) (und ja, Arrays können auch drinstehen, aber darin sind ebenfalls wieder nur Strings (und Arrays)</rekursion>). Diese GPC-Zahlenstrings müsstest du mit intval() oder floatval() oder Typecasts zwangsweise in ebendiese Typen bringen, wenn du deine Funktion gewinnbringend verwenden willst.
Nochmal zusammenfassend meine Vorschläge:
- Magic Quotes-Behandlung entfernen und an den Scriptanfang verlagern.[\*]
- Automatische typabhängige Quotierung einbauen.
- Zahlenbehandlungskonzept eventuell noch einmal überdenken und verfeinern.
- Und wenn die Funktion NULL-Werte beachten würde, wäre sie noch ein bisschen perfekter.
[\*] Am besten MQ ganz deaktivieren, denn die fallen mit PHP6 sowieso weg.
Lo!