SEwald134574 (Community Member) asked a question.
We use a fixed string SQL statement (with DbConnection and C#) and get the issue
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89).
I've no idea how SQL injection can affect this statement.
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89).
I've no idea how SQL injection can affect this statement.
Related code piece:
public void TransferDataToSystemDbExtract()
{
keyFieldValuesPerTable.Clear();
// Switch checking of foreign key violations off in the system DB extract to not be restricted in the order in which to handle the different tables.
destCommand.CommandText = "PRAGMA foreign_keys=OFF";
destCommand.ExecuteNonQuery();
.png){kind=logo}
Hello @SEwald134574 (Community Member) ,
Thank you for your question. I checked out the details of how this flaw is getting reported by Veracode Static Analyzer.
According to the flaw details, the static analyzer views the entire `destCommand` DBCommand object as the source of untrusted taint that could result in SQL injection flaw. This `destCommand` variable currently is declared in your code as a class level variable that gets re-used and referenced by other methods in the class. These other methods appear to take tainted external inputs as part of the SQL queries they are constructing and assigning to the `destCommand` DB variable. Veracode static analyzer sees this and so it marks the entire `destCommand` object itself as permanently tainted and the scanner will consider all properties assigned to this object as untrusted. This means any SQL query assigned to this class level DB object in one method will still cause Veracode to report a flaw for that method, even for supposedly safe queries that are fully hardcoded or proper parameterized. This behavior is by design because as long as the base database command object is re-used and modifiable by other methods in the class, these other methods could modify the properties of this DB instance and now reference a query that is no longer safely hardcoded or parameterized.
To remove this source of permanent taint on the `destCommand` variable, Veracode recommends an encapsulation approach where you declare the database object inside the actual class method where the SQL execution takes place. Essentially, just make `destCommand` a local class method variable instead of a shared global class level variable. Applying this change to your highlighted method and code block should remediate and remove the flaw from your report upon a re-scan.
If your team still desires to keep the current arrangement with the understanding outlined above, then you will need to submit a mitigate by design proposal statement where you explain how the current code representation cannot result in SQL injection. After drafting a proposal, please reach out to your organization's security team and ask them to review and approve the proposal. For more information on how to propose a mitigation and the process to follow to resolve flaws using this workflow, please refer to https://docs.veracode.com/r/improve_mitigation. Please note that Veracode does not approve or reject mitigation proposals.
Please let me know if you have any further questions that I can help answer. If you have any specific details about your scan findings and use case you want to discuss, then please arrange a consultation call to talk through those details. Instructions on how to request a call can be seen at https://docs.veracode.com/r/t_schedule_consultation .
Best Regards,
Andrew Bell
@Andrew Bell, Security Consultant (Veracode, Inc.) Many thanks for the comprehensive answer!
Following your suggestions I could avoid veracode issues for this and similar problems with minor changes of the source code.
Best regards,
Steffen