La inyección de SQL siempre es un tema candente, especialmente cuando se trata de seguridad web. En este sentido, estoy interesado en cuáles son los pasos que deben tomarse siempre para evitar la inyección de SQL en cualquier aplicación web. Además de estos pasos normales, ¿hay algo más que las personas hagan más allá de lo normal para evitarlo?
Ya tengo muy buenas respuestas sobre esta pregunta, sin embargo, me gustaría mencionar algunas más:
Esto es solo para prevención y no he tenido en cuenta sql server hardening . Sin embargo hay muchas similitudes.
Las defensas adicionales en caso de que ya sea vulnerable a la inyección serían:
La defensa clave es usar solo las API que escapan de forma segura a las consultas de la base de datos; a esto generalmente se les llama declaraciones parametrizadas o preparadas. No se pueden usar en todos los casos (por ejemplo, cuando se proporciona un identificador de SQL como el nombre de la tabla o columna en tiempo de ejecución), pero es el mejor enfoque cuando es posible (la mayoría de los casos).
Nota: esto puede provocar que se coloquen datos dañinos en la base de datos, así que tenga en cuenta que cuando utilice estos datos en otra parte de la aplicación
La segunda defensa es tomar un enfoque de escape. Este es el enfoque de "reemplazar una sola cita con dos comillas". Si necesita ir por este camino, debe escapar de todos los caracteres potencialmente dañinos , lo que significa más que comillas simples en algunos casos. Le aconsejaría que utilice una biblioteca de nivel superior como OWASP ESAPI, si es posible, para que haga esto por usted, o lea la Hoja de referencia de Inyección de SQL de OWASP (mencionada anteriormente) detenidamente.
El paso principal para proteger la aplicación web contra la inyección de SQL es desinfectar adecuadamente cualquier entrada del usuario (especialmente la entrada utilizada en consultas de SQL). En algunos lenguajes / marcos, hay formas estándar de manejar estos valores, por ejemplo, usando consultas parametrizadas en lugar de componer la consulta uniendo valores de cadena.
Desde el lado de la atención del desarrollador web, debe señalarse lo que Weber ya ha mencionado.
Además, se podría configurar un firewall de base de datos, como GreenSQL: enlace . Funciona como un proxy entre su aplicación y la entrada del usuario, vigila lo que se debe pasar y, etc. Sin embargo, esto conlleva un mayor tiempo de respuesta.
Estoy enseñando seguridad informática en politécnicos. A menudo, para los estudiantes tienen cierta confusión sobre los términos utilizados para la inyección de SQL, así que permítanme aclarar.
En el contexto de una aplicación web como Facebook,
La inyección SQL es cuando el usuario web normal ingresa el código SQL en los campos de datos Por ejemplo,
' OR '1'='1 into the textboxes of a login form.
La mejor persona para evitar la inyección de SQL es el desarrollador web, también conocido como el responsable de escribir el código de la aplicación web para leer / escribir datos en la base de datos.
La forma más fácil de evitar la inyección de SQL por parte del desarrollador web es usar consultas parametrizadas.
Las declaraciones preparadas y las consultas parametrizadas significan lo mismo.
Usaré consultas parametrizadas a partir de este punto.
Las consultas parametrizadas se refieren a la forma en que el código SQL se define primero y luego los datos se colocan dentro de los parámetros apropiados.
Por ejemplo, en .Net
Update 'users' set 'name' = @name where 'id' = @id
los parámetros @name y @id son los datos. El resto son el código SQL.
Tenga en cuenta que las consultas parametrizadas son generalmente pero no siempre realizadas en el código de la aplicación web.
Hay 2 formas comunes de escribir consultas parametrizadas.
Entonces, en cierto sentido, sí, los procedimientos almacenados son una forma de consultas parametrizadas.
Hay otras formas de evitar la inyección de SQL mediante el escape de caracteres especiales como comillas simples. Por ejemplo, en PHP, puede usar mysql_real_escape_string que básicamente solo coloca barras antes de las comillas simples.
Esto no es ideal debido a problemas con% y subrayado para el operador LIKE en ciertas bases de datos como MySQL. Consulte este pdf para obtener más detalles.
En pocas palabras, todas las opciones sugeridas tienen que ver con la limpieza (limpieza) de las entradas del usuario para eliminar el código SQL.
La mejor manera es utilizar consultas parametrizadas en función del lenguaje de programación utilizado.
Fin de la historia.
Utilice las API de acceso a datos decentes que facilitan hacer lo correcto, de manera segura.
Aquí está ActiveRecord v3:
# basic usage
@user = User.where(:username => '[email protected]').first
# with a SQL-string fragment, but using parameters
@projects = @user.projects.where('status = ?', params[:status])
Lea otras preguntas en las etiquetas appsec sql-injection countermeasure