LS455916 (Community Member) asked a question.
Is there a way to cleanse a utility function that is used in many places
I have a static class that provide a read-only connection string (encrypted in web.config) for use inside the application when a database connection is needed. The Veracode static scan is flagging each use of the connection string as CWE-15. We can mitigate each use but have to repeat it for all new code that use the function.
I want to make the connection string in this class safe one-time so that it can be used in many placed without causing more CWE-15 issues. An attribute similar to the custom cleaning functions used for CWE-73 or CWE-89 can be used to mark it as safe.
Does this exist or is this something that can be added to avoid repeated mitigations.
.png){kind=logo}
HI @LS455916 (Community Member) ,
Veracode Static Analysis will not report CWE 15 if it can detect that all data is coming from the ConfigurationManager. Typically this means that some other data from outside of the application is used in the connection string in some circumstances. For more information I recommend looking at the flaw description, which will have more information on the origin of the external data, for example "The tainted data originated from an earlier call to system_web_dll.System.Web.HttpRequest.get_UserHostAddress.".
We recommend that you use a connection string builder ( such as https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnectionstringbuilder?view=dotnet-plat-ext-3.1 ) and validate any data from outside of the application. Preferably with a hardcoded allow list as reducing the input to a hardcoded value will allow us to automatically close the flaw. If this is not possible you should propose a mitigation and have this mitigation reviewed by your security team.
Unfortunately, at this time we don't support custom cleansing functions for CWE 15. Please consider registering your idea with Veracode Community Ideas at https://community.veracode.com/s/ideas .
To reduce the number of flaws I would recommend centralising creation of any "SqlConnection" objects as we always report on use of the potentially dangerous connection string.
Thank you,
Boy Baukema