wpdb->insert: ¿Necesito preparar contra la inyección SQL?

15 ago 2011, 14:57:46
Vistas: 24.1K
Votos: 21

¿Necesito usar wpdb prepare antes de wpdb->insert?

Si estoy insertando valores en una tabla de WordPress usando wpdb->insert, ¿necesito "limpiar" mis datos antes de insertarlos o este método (wpdb->insert) lo hace por mí?

0
Todas las respuestas a la pregunta 3
1
24

No, no deberías preparar o escapar los datos, esto lo hace por ti la clase wpdb.

De la referencia de la clase wpdb:

data:

(array) Datos a insertar (en pares columna => valor). Tanto las columnas $data como los valores $data deben ser "crudos" (ninguno debe estar escapado para SQL).

Sin embargo, si estuvieras escribiendo tu propio SQL en lugar de usar el método insert, entonces sí, deberías escapar usando prepare.

15 ago 2011 15:23:11
Comentarios

Para agregar una nota: Tanto insert como update no lo necesitan. Pero debería usarse con query.

kaiser kaiser
15 ago 2011 15:27:33
3

Lo siguiente es una advertencia para la clase wpdb.

https://codex.wordpress.org/Class_Reference/wpdb

Una advertencia

Algunas de las funciones en esta clase toman una sentencia SQL como entrada. Debes escapar en SQL todos los valores no confiables que incorpores a la consulta SQL para prevenir ataques de inyección SQL. Revisa la documentación para ver si la función que planeas usar escapa el SQL por ti o espera que ya esté pre-escaped.

Entonces, entiendo esto como que la clase wpdb no prepara ni escapa automáticamente los datos por ti.

Estoy bastante seguro de que si no puedes confiar al 100% en la fuente de datos en tu código, entonces sugiero usar la clase prepare(?).

No pienses que usar la clase prepare lo arreglará sin usarla correctamente. Soy bastante nuevo en esto, así que por favor publica cualquier corrección como respuesta si no estoy en lo correcto.

$wpdb->prepare( "SELECT * FROM table WHERE ID = %d AND name = %s", $id, $name );

En la declaración anterior, hay 2 atributos adicionales. Uno para el ID y otro para el nombre. Según lo que he leído, cada uno corresponde en orden al número de elementos en tu consulta. Además, %s = cadena, %d = entero y %f = flotante.

También, por lo que he leído, si no incluyes los atributos adicionales, entonces prepare no hará nada. Habrá una advertencia, pero si la desactivas, quizás no te des cuenta.

Aquí hay un ejemplo de la propia referencia de clase donde agregan una clase prepare en un INSERT a continuación.

https://codex.wordpress.org/Class_Reference/wpdb#Protect_Queries_Against_SQL_Injection_Attacks

$wpdb->query( $wpdb->prepare( " INSERT INTO $wpdb->postmeta ( post_id, meta_key, meta_value ) VALUES ( %d, %s, %s ) ", array( 10, $metakey, $metavalue ) ) );

Mi preocupación es que la respuesta más votada es incorrecta según la misma página que 'nadie' referencia. Estoy asumiendo que usas prepare() pero no otros métodos estándar de escape de PHP porque tomé esta respuesta como correcta también... hasta que investigué más a fondo.

De todos modos... quizás las cosas han cambiado desde la respuesta original.

28 ago 2018 09:36:56
Comentarios

mmm, esto suena más como una pregunta que como una respuesta

Mark Kaplun Mark Kaplun
28 ago 2018 10:28:21

La respuesta aceptada es correcta. Cuando usas funciones como $wpdb->insert(), $wpdb->update()o$wpdb->delete()los datos deben estar en CRUDO. En una situación donde usas por ejemplo$wpdb->query()` y pasas una sentencia SQL como entrada, deberías escapar los datos no confiables.

nmr nmr
28 ago 2018 13:22:14

nmr, creo que ahora entiendo. Así que para aclarar... por mi cordura... lo que usaste como ejemplo son 'el método insert' y 'el método delete' en oposición a los ejemplos que yo usé de usar 'el método query' ... (%wpdb->query). ¿Debo borrar mi respuesta? ¿O dejarla?

Felixius Felixius
29 ago 2018 11:39:27
0

No, no necesitas protegerte contra inyecciones SQL cuando usas wpdb insert o wpdb delete.Descripción de la imagen

Consulta los siguientes enlaces:

https://codex.wordpress.org/Data_Validation#Database

https://codex.wordpress.org/Class_Reference/wpdb#Protect_Queries_Against_SQL_Injection_Attacks

3 dic 2018 14:24:48