mysql_real_escape_string VS addslashes

Puede alguien arrojar alguna luz sobre las diferencias entre estas 2 funciones, desde el manual de PHPmysql_real_escape_string VS addslashes

addslashes: devuelve una cadena con barras invertidas antes de personajes que necesitan ser citado en las consultas de bases de datos, etc. Estos caracteres son comilla simple ('), comillas dobles ("), la barra invertida() y NUL (el byte NULL)

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

Por lo que sé la diferencia principal es \ x00 \ n \ r \ X1A la que addslashes de escape no funciona, ¿me puede decir cuál es el significado de que es?

gracias

Fuente

2010-08-13 chicane007

Lo que se cita es probablemente del doc, pero por lo que yo sé que no es necesariamente cierto.

addslashes añade barras de caracteres que son comúnmente perturbador. mysql_real_escape_string escapa todo lo que MySQL necesita para escapar. Esto puede ser más o menos caracteres que lo que addslashes se ocupa.

Además, mysql_real_escape_string no necesariamente agregar barras de 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 addslashes puede hacer demasiado o no lo suficiente para el propósito que lo usa. Por otro lado, mysql_real_escape_stringsabe 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 ya no se usan barras diagonales inversas, su código seguirá funcionando porque mysql_real_escape_string lo sabrá.

Fuente

2010-08-13 00:33:39 zneak

ANSI SQL especifica que una comilla simple puede ser representado por dos comillas simples en una fila, pero mysql_real_escape_string() no hace eso - que siempre se escapa usando una barra invertida por lo que yo he visto. Si tiene un ejemplo de una versión de MySQL que escapa duplicando el carácter de cita, me interesaría ver el ejemplo. –

@BillKarwin, 'mysql_real_escape_string' de PHP llama de MySQL [' mysql_real_escape_string'] (http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html), que hace lo que quiere para escapar de las cuerdas. La documentación de PHP ahora dice que usa barras negras, pero la documentación de MySQL no dice nada al respecto. Recuerdo que en algún momento se escaparía con ' ''' en lugar de '\ '', tal vez eso no es el caso más, o tal vez requiere configuraciones de conexión específicos (' mysql_real_escape_string' toma un argumento de conexión para que pueda revisarlos después todas). – zneak

Aha, que probó y descubrió que si se establece 'sql_mode = NO_BACKSLASH_ESCAPES' se comporta como usted describe. Mi confusión se debe a que 'mysqldump' todavía no tiene los caracteres de comillas dobles, incluso si tiene ese modo sql establecido. ¡Lo que significa que puede crear un archivo de volcado que no puede ser reimportado en el servidor que lo generó! –

Ignore ambos y solo use consultas parametrizadas. A menos que, por supuesto, te gusten los ataques de inyección.

Fuente

2010-08-13 00:38:50 afrazier

Para completar, ¿podría hacer referencia a las funciones/clases a las que desea cambiar? Vengo de un fondo de Postgres, así que sé usar las funciones ps_ o PDO, pero no sé qué es compatible con las consultas parametrizadas para un usuario de MySQL. – Tom

El uso constante de 'mysql_real_escape_string' evitará ataques de inyección. –

Las generalizaciones vagas no son muy útiles. – cbednarski

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

La función de PHP mysql_real_escape_string() utiliza la función API MySQL C del 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 conocido experto en seguridad de PHP Chris Shiflett, para una demostración de que se puede obtener explotación de la inyección de SQL, incluso si usa addslashes().

Otras personas recomiendan el uso de parámetros de consulta, y luego usted 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 se puede utilizar parámetros de consulta para un valor de cadena dinámica, al igual que su patrón de búsqueda en una búsqueda de texto completo.

Fuente

2010-08-13 00:41:04

+1 para material de lectura. Es bueno estar informado sobre estos temas. – cbednarski

"tengo que cambiar a PDO" me parece un beneficio. – Tom

@Tom: Sí, prefiero PDO y lo recomiendo. Pero si un proyecto ya tiene muchos códigos usando ext/mysql, es difícil justificar el tiempo para reescribirlo todo. –

Había 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 necesita, pero probablemente no lo sean.

Como @afrazier dice, se debe utilizar prepared statements

Fuente

2010-08-13 00:41:24 jeremiahd

En lugar de preparar "ies usando DOP puede utilizar esto mientras que la aplicación utiliza MySQLi (¡cuidado! "Quer i" en y de MySQL")

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

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

Fuente

2013-10-14 18:05:21

mysql_real_escape_string VS addslashes

Respuesta

Cuestiones relacionadas