El proyecto que utiliza [Dapper] es informado por Veracode como CWE ID 89 (Neutralización inadecuada de elementos especiales utilizados en un comando SQL)

.net asp.net dapper veracode wce

Pregunta

Tenemos un proyecto .Net 4.0 que Veracode escanea para adquirir la certificación de seguridad.

Durante el análisis estático, se ha encontrado la siguiente vulnerabilidad: Neutralización inadecuada de elementos especiales utilizados en un comando SQL ('Inyección SQL') (CWE ID 89) Consulte los detalles en https://cwe.mitre.org/data/definitions/89. html

El informe detalla el archivo y el número de línea que parece referirse a Dapper:

OurOwnDll.dll dev /.../ dapper net40 / sqlmapper.cs 1138

App_Browsers.dll dev /.../ sqlmapperasync.cs 126

OurOwnDll está utilizando Dapper.

App_Browsers.dll No sé de dónde viene, pero parece estar relacionado con el proyecto del sitio, y parece estar relacionado con la detección de asp.net de las capacidades de los navegadores.

Me gustaría saber si hay alguna forma de prevenir esta vulnerabilidad.

Respuesta popular

No estoy familiarizado con VeraCode, sin embargo, como señala @Kristen Waite Jukowski, su problema puede deberse al hecho de que algunas de sus consultas no están parametrizadas, en cuyo caso se identifican correctamente como vulnerables a la inyección de SQL.

Alternativamente, una pregunta similar (relacionada con el mismo problema pero con OrmLite) puede arrojar algo de luz sobre esto. Similar a OrmLite, ya que dapper proporciona la posibilidad de escribir consultas SQL sin formato que podrían componerse con entradas que no están parametrizadas (por ejemplo, mediante concatenación de cadenas), usarlas puede considerarse una vulnerabilidad, incluso si cada consulta en su proyecto particular es actualmente completamente parametrizado La respuesta a esa pregunta (que puede no ser viable en su caso) fue reemplazar el ORM existente con Entity Framework:

Durante una lectura de código con VeraCode, la solución correcta sugerida era reemplazar ServiceStack ORM con EntityFramework 6.1.

De los comentarios en esa pregunta:

La diferencia está en EF, el contexto de ejecución implementa IDbCommand pero el CreateDataAdapter y otras api que pueden permitir el sql dinámico se han implementado para lanzar excepciones. No hay rutas de código en EF que permitan SQL dinámico sin antes pasar por un mecanismo de filtrado similar a OWASP.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué