SQLi-protection ORDENAR POR

Navega tus respuestas
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.

    
pregunta Filip Haglund 30.01.2013 - 13:13
fuente

3 respuestas

3

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.

    
respondido por el Jeff 30.01.2013 - 20:29
fuente
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 - 13: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:

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

Enlaces útiles:

respondido por el Akam 30.01.2013 - 20:00
fuente

Lea otras preguntas en las etiquetas

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?