Hello @pradeeprj49 (Community Member)​ ,

Thanks for your question. You are right to point out that prepared statements cannot be deployed for SQL queries where you insert dynamic values into a column name field. This would mainly impact the ORDER BY clause in the SQL query you've shared here.

For this case, I would recommend having a read through the solutions in the below articles Veracode has posted on how you can respond to reported SQL injection flaws. The second link actually covers the scenario of having dynamic column names in your SQL query:

https://community.veracode.com/s/article/How-to-fix-CWE-89-SQL-Injection-flaws

https://community.veracode.com/s/article/sql-injection-mitigation-page2

Basically, the best way forward for this kind of SQL query is to enforce strict allow-list input validation such that your SQL statement only accepts approved column name values and formats that won't permit SQL injection attacks. The other recommended option would be query redesign to see if you can rewrite the query in a way where you do not read column names from dynamic external user input and instead read from the code or trusted configuration files. Based on your title for this question, your team might have already considered this and determined it to be a non-starter for your use case, which is fine -- in these situations, going with allow-list input validation is the primary fallback approach we suggest here.

Note that Veracode static analyzer by its nature can not recognize and evaluate dynamic input validation schemes as a fix to auto resolve CWE-89 flaws. This means that after you've added in input validation controls to your code and tested that they function properly, you will need to propose a mitigation and discuss it with your organization's Security Team for their review and approval. 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.

Depending on what type SQL database your application uses here, it might also be the case that you are unable to bind and parameterize dynamic values to the LIMIT and OFFSET clauses. If this applies to your case as well, then it should also be fine to parse and validate these values as strict integers before you append these to your query as a suitable mitigation. You still will need to make use of Veracode's mitigation proposal process to resolve the flaws with this approach.

Please let me know if you have any further questions regarding this issue.

Best Regards,

Andrew Bell