Si usa mysql_real_escape_string constantemente cada vez que inyecta contenido en un literal de cadena SQL, está bien, no hay ningún problema de seguridad.
Sin embargo, lo que el tiempo nos ha enseñado es que:
-
Es difícil capturar cada lugar que inyectas en un literal de cadena SQL. En el mundo real, los casos no escapados a veces se pasan por alto, incluso cuando el codificador original entiende el escape de SQL correctamente. O las inyecciones crudas se agregan más tarde en el mantenimiento. O se omite el escape cuando el codificador cree que no hay posibilidad de que haya caracteres especiales en la cadena, pero luego algo cambia y esa suposición ya no es cierta.
-
Despachar sus consultas con ...'.mysql_real_escape_string($value, $db).'... las hace tediosas y difíciles de leer.
-
La gente aún no entiende el problema de codificación con el que real se relaciona y, por lo tanto, no logra establecer el conjunto de caracteres de la manera correcta ( mysql_set_charset() , no está mal SET NAMES ).
Podemos pasar el resto del tiempo persiguiendo estos problemas en el código escrito con la extensión mysql , o simplemente empujar a todos para que utilicen consultas parametrizadas, que funcionan correctamente sin requerir un conocimiento profundo del procesamiento de cadenas.