Las inyecciones SQL normales no son un problema ya que siempre uso declaraciones preparadas, pero cómo protegerme de inyecciones SQL de segundo orden ?
Las inyecciones SQL normales no son un problema ya que siempre uso declaraciones preparadas, pero cómo protegerme de inyecciones SQL de segundo orden ?
Una inyección SQL de segundo orden es una inyección donde la carga útil ya está almacenada en la base de datos (en lugar de decir que se entrega en un parámetro GET). En ese sentido, es algo similar al XSS almacenado (y la inyección de SQL de "primer orden" ordinaria sería análoga al XSS reflejado).
¿Cómo funciona? Digamos que dejas que los usuarios elijan cualquier nombre de usuario. Así que un atacante podría elegir el nombre '; DROP TABLE Users; -- . Si concatena ingenuamente este nombre de usuario en su consulta SQL para recuperar información sobre ese usuario, tiene un problema:
sql = "SELECT * FROM Users WHERE UserName = '" + $username + "'";
Entonces, ¿cómo lidias con esto?
Utilice siempre consultas parametrizadas, siempre, siempre, siempre. Trate todas las variables como datos de usuario no confiables, incluso si se originan en la base de datos. Simplemente simule que todo son parámetros GET y actúe en consecuencia al vincularlos como parámetros.
También puede sanear y limitar la entrada (por ejemplo, solo permitir nombres de usuario alfanuméricos) antes de que se almacene en la base de datos y después de que se recupere de la base de datos. Pero no confiaría en eso como mi única línea de defensa, así que también use consultas parametrizadas.
No hay nada 'especial' aquí. La llamada inyección de SQL de "segundo orden" es la misma inyección de SQL con la pequeña diferencia de que el contenido proviene de la base de datos en lugar de los datos ingresados directamente por el usuario. Se aplican las mismas reglas
siempre desinfecte los datos de entrada sin importar de dónde vengan (el usuario, un archivo, una base de datos, etc.)
Nunca use concatenación de cadenas para crear comandos ejecutables. Use declaraciones preparadas, etc.
La regla general es nunca confiar en ningún dato de entrada, independientemente de qué tan seguro creas que podría ser. No puede confiar en lo que el usuario podría ingresar y debe asumir que incluso sus propios repositorios de datos (es decir, su base de datos) pueden haber sido comprometidos de alguna manera o haber tenido "datos erróneos". Escriba su código asumiendo que se está ejecutando en un entorno hostil como es la realidad, usted es.
Por cierto, veo que la documentación de Oracle no ha mejorado! Esa es una nota muy mal redactada y mal explicada con respecto a la inyección de SQl.
Lea otras preguntas en las etiquetas sql-injection mysql