php - ejemplos - mysql_real_escape_string VS addslashes

php mysqli

Question

¿Puede alguien arrojar algo de luz sobre las diferencias entre estas 2 funciones, desde el manual de PHP

addslashes: devuelve una cadena con barras diagonales inversas antes de los caracteres que deben citarse en las consultas de la base de datos, etc. Estos caracteres son comillas simples (''), comillas dobles ("), barras invertidas () y NUL (el byte NULO).

mysql_real_escape_string: mysql_real_escape_string () llama a la función de biblioteca de MySQL mysql_real_escape_string, que antepone barras diagonales inversas a los siguientes caracteres: / x00, / n, / r, /, '', "y / x1a.

de lo que deduzco que la mayor diferencia es / x00, / n / r / x1a, que agrega que las pestañas no escapan, ¿puedes decirme qué significa eso?

Gracias

Answer 1

En lugar de preparar consultas usando PDO, puede usar esto mientras su aplicación usa MySQLi (¡cuidado! "I" en y de Mysql ")

$nick = $connect->real_escape_string($nick);
$nick= addcslashes($nick, ''%_'');
$pass = $connect->real_escape_string($pass);
$pass = addcslashes($pass, ''%_'');

Answer 2

Hubo un montón de historia con mysql_escape_string y mysql_real_escape_string . Ambos fueron intentos de proporcionar un mecanismo de escape "general" que minimizaría la probabilidad de ataques de inyección sql.

mysql_real_escape_string y addslashes están bien, si son lo que realmente necesitas, pero probablemente no lo sean.

Como dice @afrazier, debes usar declaraciones preparadas

Answer 3

Ignora ambos y simplemente usa consultas parametrizadas. A menos que, por supuesto, te gusten los ataques de inyección.

Answer 4

Lo que citas es probablemente del doc, pero hasta donde yo sé, no es necesariamente cierto.

addslashes agrega barras diagonales a caracteres que son comúnmente molestos. mysql_real_escape_string escapa de lo que MySQL necesita para escapar. Esto puede ser más o menos caracteres de lo que se encarga el addslashes .

Además, mysql_real_escape_string no necesariamente agregará barras para escapar. Si bien creo que funciona si lo haces de esa manera, las versiones recientes de MySQL escapan de las citas juntando dos de ellas en lugar de poner una barra antes.

Creo que siempre debe usar la función de escape de su proveedor de datos en lugar de addslashes , porque las addslashes pueden hacer demasiado o no funcionar para el propósito que usa. Por otro lado, mysql_real_escape_string sabe qué hacer para preparar una cadena para incrustarla en una consulta. Incluso si las especificaciones cambian acerca de cómo escapar de las cosas y de repente no se trata de barras diagonales inversas que debe usar más, su código seguirá funcionando porque mysql_real_escape_string sabrá.

Answer 5

mysql_real_escape_string () también tiene en cuenta el juego de caracteres utilizado por la conexión actual a la base de datos.

La función de PHP mysql_real_escape_string () usa la función de la API C de MySQL con el mismo nombre: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-escape-string.html

Lea también addslashes () Versus mysql_real_escape_string () por el destacado experto en seguridad PHP Chris Shiflett, para una demostración de que puede obtener exploits de inyección de SQL incluso si usa addslashes ().

Otras personas recomiendan usar parámetros de consulta, y luego no tiene que hacer ningún escape de valores dinámicos. También lo recomiendo, pero en PHP tendrías que cambiar a PDO o ext / mysqli, porque la API plain ext / mysql no admite parámetros de consulta.

También puede haber algunos casos de esquina donde no puede usar parámetros de consulta para un valor de cadena dinámico, como su patrón de búsqueda en una búsqueda de texto completo.