We have a .Net 4.0 project that is being scanned by Veracode in order to acquire security certification.
During static scan the following vulnerability has been found: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE ID 89) See details at https://cwe.mitre.org/data/definitions/89.html
The report details file & line number that seems to refer to Dapper:
OurOwnDll.dll dev/.../dapper net40/sqlmapper.cs 1138
App_Browsers.dll dev/.../sqlmapperasync.cs 126
OurOwnDll is using Dapper.
App_Browsers.dll IÂ´m not aware where it is coming from, but seems to be related to the site project, and seems to be related to the browsers capabilities detection of asp.net.
I would like to know if there is any way to prevent this vulnerability.
I am not familiar with VeraCode, however as pointed out by @Kristen Waite Jukowski, your issue may be due to the fact that some of your queries are not parameterised, in which case they are correctly being identified as vulnerable to SQL injection.
Alternatively, a similar question (relating to the same issue but with OrmLite) may shed some light on this. Similar to OrmLite, as dapper provides the facility to write raw SQL queries that could be composed with inputs that are not parameterised (for example by string concatenation), using it may be deemed a vulnerability, even if every query in your particular project is currently fully parameterised. The answer to that question (which may not be viable in your case) was to replace the existing ORM with Entity Framework:
During a code-readout with VeraCode the suggested proper remediation was to replace ServiceStack ORM with EntityFramework 6.1.
From the comments in that question:
The difference is in EF, the executing context implements IDbCommand but the CreateDataAdapter and other api's that can allow dynamic sql have been implemented to throw exceptions. There are no code paths in EF that allow dynamic sql without first going through a filtering mechanism similar to OWASP.