SQLi-protection ORDENAR POR

Question

SQLi-protection ORDENAR POR

#1 de Jeff (3 votos)
#2 de sujeesh (1 votos)
#3 de Akam (0 votos)

4

¿Qué sería una buena verificación para eliminar todas las posibilidades de inyección de SQL en un ORDER BY col donde col es una variable no segura?

Actualmente estoy eliminando [^A-Za-z0-9_] de la cadena en php. ¿Es esto demasiado paranoico o tal vez no sea suficiente?

EDITAR:

Solo para aclarar: estoy buscando una manera de eliminar cualquier SQLi de un ORDER BY $unsafeVariable , no una solución general de prevención de SQLi. Ya estoy usando las consultas preparadas y pdo :: quote cuando sea necesario, pero como tenía que incluir una variable no segura en una declaración order by , pensé que pediría la opinión de alguien más.

sql-injection php

pregunta Filip Haglund 30.01.2013 - 12:13

fuente

3 respuestas

1

Por favor, no sientas que solo estoy dando algunos enlaces y no explicaciones. Pensé que todas las respuestas están en esos enlaces y será bueno en lugar de copiar el mismo texto aquí. Si desea consultar más sobre seguridad, entonces los enlaces serán útiles. Simplemente marque enlace y obtenga una idea sobre cómo prevenir sqli en php.
Para leer más sobre la seguridad de php, lea enlace .

respondido por el sujeesh 30.01.2013 - 12:28

fuente

0

Considero que su solución es una protección de primera capa contra la inyección de SQL o cualquier ataque de inyección de código (XSS), es un requisito para borrar los datos de entrada del usuario antes de enviarlos a la base de datos. Confundí con algunas personas que recomendaban una consulta preparada (parametrizada). consultar) y usar el procedimiento almacenado, porque no hay lógica para enviar un parámetro no seguro a la base de datos si se puede limpiar antes, pero, para mayor seguridad, también se requiere el uso de los métodos mencionados.

(nota: la idea detrás de la consulta parametrizada es que la base de datos puede distinguir entre la consulta original y los datos que se usaron para construir esa consulta) (owasp, 2012) [4]

algunas reglas que siempre las uso:

Use la última actualización / la última tecnología (actualice con frecuencia, instale parches y correcciones)
Limpie los datos de entrada del usuario antes de usarlos dentro de la consulta
Utilice menos privilegios de usuario al crear una consulta dinámica, elimine el privilegio no requerido para seleccionar una consulta
Supervisar la integridad de los archivos y datos críticos.

Enlaces útiles:

[1] enlace
[2] enlace
[3] enlace
[4] enlace

respondido por el Akam 30.01.2013 - 19:00

fuente

Lea otras preguntas en las etiquetas sql-injection php

iPad como terminal de acceso seguro ¿Es la compresión de archivos NTFS vulnerable a un ataque de tipo CRIME cuando se usa un volumen cifrado?

score 3 · Accepted Answer

La mejor solución es si conoce todas las columnas de ORDER BY permitidas por adelantado y verifique su $ unsafeVariable en esa lista blanca.
Otra opción: después de eliminar todos los caracteres no válidos, compruebe que su $ unsafeVariable es una subcadena de la consulta que está creando. Sería extremadamente difícil hacer un mal uso de eso.