¿Es seguro concatenar variables de sesión sin entrada en una cadena SQL?

Question

¿Es seguro concatenar variables de sesión sin entrada en una cadena SQL?

#1 de Conor Mancone (5 votos)

1

Tengo una aplicación php en la que la función "makeSessionVar" crea una variable de sesión a partir de los datos definidos por la aplicación y luego la concatena en la cadena SQL.

function makeSessionVar($A,$B){ // (<id>, <sql column name>); 
    ...
    $_SESSION['col'.$A] = $B;
    ...
}

makeSessionVar("1", "dateModified"); 
makeSessionVar("2", "title");
makeSessionVar("3", "notes");

$editSQL = "UPDATE myTable SET " . $_SESSION['col1'] . " = ?,  " . $_SESSION['col2'] . " = ?,  " . $_SESSION['col3']. " = ? WHERE ID = ?";

Tengo entendido que la concatenación es peligrosa para los datos definidos por el usuario, pero ¿hay una manera para que un usuario final envenene estas variables de sesión para inyectar un código arbitrario, o es seguro?

Sí, sé que la forma correcta es hacer una declaración completamente preparada como la que se muestra a continuación, pero me interesa más saber si realmente importa desde un punto de vista de seguridad.

$editSQL = "UPDATE myTable SET ? = ?,  ? = ?,  ? = ? WHERE ID = ?"

php mysql injection

pregunta Nosajimiki 12.10.2018 - 19:30

fuente

1 respuesta

Lea otras preguntas en las etiquetas php mysql injection

¿Es una mala práctica usar los últimos 4 dígitos de un número de seguro social como identificador? Mala seguridad médica

score 5 · Accepted Answer

Suponiendo que las consultas preparadas son fáciles de usar y no causan problemas de rendimiento aquí, entonces solo debe usar las consultas preparadas. Si todo lo demás es igual, prefiero hacer las cosas de forma segura por defecto. En otras palabras, en lugar de preguntar "¿Debo hacer esto de manera segura?" (que es lo que está preguntando) intente acercarse desde la perspectiva opuesta: "¿Hay alguna razón no para hacerlo de forma segura?". A menos que tenga una buena razón para hacerlo sin consultas preparadas, siempre úselos.

Para las variables de sesión, creo que es especialmente importante utilizar siempre las consultas preparadas, ya que su naturaleza hace que sea más fácil perder la pista de dónde provienen. Es cierto que, dado su caso de uso actual, no existe un riesgo inmediato de una vulnerabilidad de inyección de SQL (pero tenga en cuenta que los datos de sesión y los datos de cookies pueden confundirse fácilmente, y estos últimos no son seguros). Sin embargo, las necesidades comerciales cambian a menudo y esto puede generar un gran riesgo cuando la creación de datos no es fácilmente "visible" desde donde se usa. ¿Qué sucede si en la próxima iteración de la aplicación uno de estos datos ahora proviene de la opinión del usuario? Probablemente recuerde convertir su consulta en una consulta preparada cuando almacene por primera vez la entrada del usuario. Pero, ¿recordará seguir esos mismos datos a través de toda la aplicación y asegurarse de que no los esté utilizando sin las consultas preparadas más adelante? Si terminas insertando los datos en la base de datos de manera segura, pero luego obtienes esos datos de la base de datos y los usas en otra consulta insegura, entonces puedes terminar con una vulnerabilidad de inyección de SQL.

Así que no preguntes "¿Debo usar consultas preparadas?". En su lugar, comience por el otro extremo: "¿Hay alguna razón por la que no deba usar las consultas preparadas?". Si no tiene una razón convincente para omitir las consultas preparadas, entonces úselas. Si crees que tienes una buena razón para hacerlo de forma insegura, al menos estás en un buen punto de partida para un análisis exhaustivo de costo / beneficio.

Consultas preparadas con nombres de columna variables

Tenga en cuenta que esta sintaxis no está permitida para consultas preparadas:

$editSQL = "UPDATE myTable SET ? = ?, ? = ?, ? = ? WHERE ID = ?"

Los nombres de columna no se pueden proporcionar con marcadores de posición. Como resultado, en realidad no puede generar consultas preparadas como esta. En su lugar, debe proporcionar los nombres de las columnas como variables en la construcción de consultas, lo que significa que puede ser vulnerable a las vulnerabilidades de SQLi. Por lo tanto, la forma de protegerse contra SQLi en casos como este es en la lista blanca del contenido de la variable para asegurarse de que sea exactamente lo que se supone que es.