Hello,

This type of flaw is usually about data being pulled out of configuration and then sent out of the application. Our scanner has made the guess that you keep sensitive data in the configuration of your application. It is also possible that there is data in your config that is not sensitive, and there's no problem sending it off.

The first step in triaging these flaws is to check which variable originated in the config, and then determine if it is exposing any sensitive data concerning your application. If it is not, you might want to follow the workflow to mark the flaw as mitigated.

Hi,

For CWE-201, remediation of the flaw requires that sensitive data not be sent externally from the application. It is unclear in the snippet where the sensitive data is originating, but one common place is usually due to data being retrieved from a configuration file. The scanner assumes that sensitive data is present in the configuration file. It is possible that there is data in the configuration file that is not sensitive that you are retrieving, but the scanner is not able to determine that itself. It is recommended to triage where the data is originating, understand what data is being sent, and determining whether the information is sensitive.

If the data is sensitive, it is recommended to remove it from requests being sent externally.

If the data is not sensitive, it is recommended to use a mitigation to document what the data is, its purpose, and the recipient consuming the data. This information can help identify contextual sensitivity of the data. A mitigation approver can then review the mitigation statement and approve it if they agree that the data is not sensitive according to your organization's information security policies.

For more information, see "Mitigating Flaws" in our help center: https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ

If you have any other questions, I would recommend you schedule a consultation call to discuss, https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/bLo7cMy~2mOWtJ~kbrVzDg , or you can send an email to Support@veracode.com with the application and scan name so we can look into the identified flaw to provide you more specific feedback.

Regards,

Veracode Application Security Consulting Team

@Boy, Security Consultant (Veracode)​ 

Here is a specific scenario for CWE-201 in our .NET application that I don't understand:

var client = new HttpClient();

var builder = new UriBuilder("http://localhost/api/users/self");

var response = await client.GetAsync(builder.ToString());

Note: I've changed the above code to make it a simple example. Originally it was using the builder to incrementally build the URL based on configuration (rather than a static URL). HOWEVER, even after changing it to the above example, with the static URL, the static scan still flags this as CWE-201 with description:

The application calls the system_net_http_dll.System.Net.Http.HttpClient.GetAsync() function, which will result in data being transferred out of the application (via the network or another medium). This data contains sensitive information. GetAsync() was called on the client object, which contains potentially sensitive data. The potentially sensitive data originated from an earlier call to mscorlib_dll.System.Security.Cryptography.RijndaelManaged.CreateDecryptor.

I have no idea why it is complaining about the System.Security.Cryptography.RijndaelManaged.CreateDecryptor. That is not being used at all in the code that the flaw is pointing to.

We have a dozen or so of these CWE-201's popping up in our application. Just about all of them reference that RijndaelManaged class. All I can think is the static analyzer is getting confused for some reason. I've scheduled a call to review, but just thought I'd post here for posterity.