Hi @JGe356144 (Community Member)​ ,

Great question! Once the custom cleanser feature is enabled for your account, the Security Lead or Veracode Administrator will need to decide on what should happen when the Veracode Platform sees a Veracode Annotation within your application scan. Here are the 3 possible options:

1. None - This is the default setting when the feature is enabled by Veracode. The Veracode Platform will do nothing if it sees a Veracode Annotation in your code.
2. Propose - This is the most common option among our customer base. The Veracode Platform will auto-propose a mitigation for the flaw class reported by the Veracode Static Analysis Tool. The flaw reported will have a mitigation status of propose and if you expand on the flaw details, you will see "Proposed by Custom Cleanser Function" with comments stating cleansing method with the Veracode Annotation.
3. Approve - This is not recommended and should be carefully discussed/reviewed before enabling. The Veracode Platform will auto-propose a mitigation as well as auto-approve the mitigation for the flaw class reported by the Veracode Static Analysis Tool without any review or acknowledgment of the mitigating controls.  

For more information on custom cleansers, please review https://community.veracode.com/s/article/How-To-Use-Custom-Cleanser .

Based on your description, either the default setting of "None" is still in place for your account or you might already find some auto-proposed mitigations for these flaws, which need to be approved by your security team for the flaw to not affect your policy anymore.

Thank you,

Florian Walter

Thanks for the reply. Yes, they are in the proposed state. However, the code I put in should solve the issue, not only propose the mitigation.

Url.IsLocalUrl() is VeraCode approved method to solve the URL redirect issue. I expected VeraCode scan recognized the code and remove the issues.

Thanks,

Jason

Hi @JGe356144 (Community Member)​ ,

Url.IsLocalUrl() is a decent way to deal with CWE 601 (URL Redirection to Untrusted Site ('Open Redirect')). The reason why Veracode Static Analysis still flags this is that you outsource the check into an external function. For a human, it is very easy to see in your example that all control-flow paths either involve the Url.IsLocalUrl() check or make sure that a passed URL is null or whitespace, i.e. cannot be malicious. But for static analysis, this is very hard. I recommend that you move the Url.IsLocalUrl() close to the actual redirect, which should automatically close the flaw. For example:

if (Url.IsLocalUrl(url))

{

        return Redirect(url); // Should not be flagged by our engine

} 

If that is not an option, then using the custom cleanser like you already do might be a proper solution for you.

Thank you,

Florian Walter

Hi Florian,

Your last recommendation of moving Url.IsLocalUrl() close doesn't align with the idea of Custom Attribute based cleaning methods.

We are thinking of creating the set of 100% effective custom cleansers for Redirect , 117 Log cleaning and get that reviewed by our security team and then get a 3. Approve settings so that we don't need to worry during each code change. Just imagine a line is changed on a controller and all the mitigated issues has to be readdressed!

So we are looking to get an method which will satisfy the scanner and  Url.IsLocalUrl()  is a recommended cleanser method. Do we need to add anything more? Clean up on the requestFrom to remove any suspicious values - or put some other cleaning methods on requestFrom?

var requestFrom = Request.QueryString["requestFrom"];