Capa de abstracción de SQL: ¿Un mecanismo preventivo para SQLi?

4

Al realizar un pentest para una aplicación basada en Java, encontré un error de SQL (en realidad, HQL) simplemente colocando una comilla en uno de los parámetros de solicitud y rompiendo la sintaxis de la consulta. Pero como la aplicación hizo uso del lenguaje de consulta Hibernate como capa intermedia entre la aplicación y la base de datos, no pude acceder directamente a la base de datos.

HQL no es compatible con los controles basados en la Unión o el retardo de tiempo que generalmente explotamos como pentesters. Solo pude extraer todas las entradas de la tabla en cuestión. Tenga en cuenta que como la inyección se encontró en una función de búsqueda simple, no había datos confidenciales en la tabla. No he podido extraer ninguna base de datos o información relacionada con el sistema.

Ya he consultado esta pregunta . Mi pregunta aquí es, ¿se puede sugerir el uso de una capa de abstracción como una medida preventiva durante la fase de desarrollo de una aplicación? Porque, según tengo entendido, realmente puede minimizar el daño potencial de una vulnerabilidad de SQLi (al menos en mi caso dado donde no hay datos críticos reales en la base de datos)

¿Estoy perdiendo algo importante aquí?

    
pregunta Shurmajee 26.05.2014 - 22:10
fuente

2 respuestas

2

Usar una capa de abstracción no es una prevención significativa; las aplicaciones que utilizan dichas capas son a menudo vulnerables a la inyección de SQL.

Siguiendo con tu ejemplo de Hibernate, algunas formas de consultar son seguras; Algunas formas son inseguras. En realidad no he encontrado un ejemplo como el que usted describe que es parcialmente seguro, pero tiene sentido. Me he encontrado con varios que son efectivamente inyección directa de SQL.

Por lo tanto, con una capa de abstracción en su lugar, usted todavía está confiando en los desarrolladores para que utilicen la API de consulta segura. Esto no es tan diferente de las interfaces SQL estándar (como JDBC) donde hay una API segura (consultas parametrizadas) y una API insegura (creación dinámica de SQL). De cualquier manera, usted confía en que los desarrolladores utilicen el correcto.

Podría preguntarse, ¿alguien ha inventado una biblioteca de abstracción que solo tiene una API segura? Si no hay una API insegura, entonces no hay nada que los desarrolladores puedan abusar. Que yo sepa, no existe tal biblioteca, y esto se debe a que existen extrañas ocasiones en que se necesita la API insegura. Recuerde que el uso de la API insegura no es necesariamente una vulnerabilidad de seguridad: es posible que el código solo use datos de fuentes confiables, o que haga su propia limpieza.

Así que las defensas son:

  • Elija una buena biblioteca, una con una API segura que sea fácil de usar
  • Desarrolle estándares de codificación que exijan una API segura y capacite a los desarrolladores para que utilicen este
  • Realice una revisión por pares o un análisis de código estático para imponer el uso de la API segura
  • Utilice las pruebas de penetración y WAF como una capa final de defensa
respondido por el paj28 26.05.2014 - 23:12
fuente
0

Es genial que la capa de abstracción impida el acceso directo a la base de datos, pero no confiaría en ella como su único resguardo. Si tienes una capa de abstracción en su lugar porque la aplicación se basa en ella para su uso, y te ayuda a bloquear SQLi, está muy bien. Pero no implementaría una capa de abstracción SÓLO por motivos de seguridad. Hay muchas otras formas documentadas de vencer a SQLi que son más fáciles de implementar. SQLi tiene que ver con las aportaciones del usuario y pasarlo a través de una capa más no será tan efectivo como detenerlo antes de que tenga la oportunidad de acercarse a la base de datos.

    
respondido por el Jason Higgins 26.05.2014 - 22:41
fuente

Lea otras preguntas en las etiquetas