¿El uso de bases de datos que no son SQL evita la necesidad de protegerse contra & # 8220; inyección SQL # 8221 ;?

Question

Esto puede parecer una pregunta obvia (o no tan obvia), pero déjame explicarte. Estoy codificando un sitio de Google App Engine usando la tecnología de base de datos de Google, BigTable. Cualquier codificador de App Engine sabrá que Google tiene su propio lenguaje de consulta limitado llamado GQL. Como resultado, me siento tentado a no hacer ninguna comprobación de inyección de SQL (o GQL) en mi aplicación, ya que supongo que Google no está utilizando una consulta de cadena sin procesar en sus métodos de back-end para obtener datos.

Además, las bibliotecas para tecnologías de bases de datos como CouchDB, MongoDB y otras bases de datos de objetos o documentos (también conocido como NoSQL) parecen obviar la necesidad de verificar si un usuario malintencionado está inyectando comandos de manipulación de bases de datos. A menudo tienen bibliotecas que mapean directamente los objetos en la base de datos para objetar en el idioma de su elección. Sé que hay muchas bibliotecas de SQL que también hacen esto, pero supongo que en algún nivel están combinando parámetros para ejecutar una consulta en una cadena, y por lo tanto todavía debo usar la protección de inyección SQL incluso con esos marcos.

¿Estoy siendo miope? ¿O es solo cuestión de tiempo hasta que el próximo gran sistema de DB tome el control y luego vea la inyección en esos sistemas?

Answer 1

& # 8220; Inyección & # 8221; los agujeros tienen que ver con los desajustes de contexto de texto. Cada vez que coloca una cadena de texto en otro contexto de cadena, necesita hacer una codificación que se ajuste al contexto cambiado. Parece seductoramente simple juntar cadenas a ciegas, pero la dificultad del procesamiento de cadenas es engañosa.

Las bases de datos con una interfaz puramente basada en objetos son inmunes a las vulnerabilidades de inyección, al igual que las consultas parametrizadas en SQL. No hay nada que un atacante pueda poner en su cadena para salir del contexto literal de la cadena en el que lo ha puesto.

Pero GQL específicamente no es uno de estos. Es un lenguaje de consulta de cadena, y si concatena material no escapado no confiable en una consulta como " WHERE title = '% s' " % title , eres tan vulnerable como lo eras con SQL completo. Tal vez las capacidades limitadas de GQL hacen que sea más difícil explotarlo para comprometer completamente la aplicación, pero ciertamente no es imposible en general, y en el mejor de los casos su aplicación sigue siendo incorrecta y se caerá cuando las personas intenten usar apóstrofes legítimamente. / p>

GQL tiene una interfaz de enlace de parámetros. Úsalo. Resiste el encanto de la piratería de cadenas.

Answer 2

Los subconjuntos SQL como GQL obviamente todavía se preocupan por él, pero las bases de datos no SQL como CouchDB, Voldemort, etc. deberían poner & amp; obtener datos sin preocuparse por los ataques de estilo inyección SQL.

Sin embargo, eso no lo excusa de validar el contenido, ya que si bien es posible que no rompa la base de datos, puede dañar su aplicación y permitir cosas como XSS (si es una aplicación web).

Answer 3

Cada vez que los datos que provienen o son manipulados por la entrada del usuario se utilizan para controlar la ejecución del código, es necesario desinfectarlos. He visto casos en los que el código usaba la entrada del usuario para ejecutar un comando sin desinfectar la entrada. No había sido explotado, pero si lo hubiera sido, habría sido un horrible vector de ataque.

Answer 4

La inyección SQl es solo un subconjunto de un tipo de falla de seguridad en el que se evalúa cualquier entrada no controlada.

técnicamente, podría "inyectar" javascript, entre otros.