Hello @nuttam595474 (Community Member)​ ,

Thanks for reaching out with your issue. The .NET Html.raw() function is not recognized as an appropriate fix for CWE-80 Cross-Site Scripting (XSS) flaws because the function does not perform any output encoding of special HTML characters . The function simply returns and renders the HTML markup as is and will not neutralize any special HTML characters that a malicious user could add in order to get your application to execute arbitrary scripts. Because of this, Veracode static analyzer views and treats HTML.raw() as a risky XSS vulnerable method that can place your application at risk should it accept tainted, untrusted input into this method.

To fix and remediate these flaws, you need to have your application mention a proper HTML output encoding method around the returned HTML markup Veracode static analyzer has reported. It needs to be a recognized method that is known to properly cleanse and neutralize any special HTML input before it is rendered for presentation and display in your web app frontend. Veracode static analyzer already recognizes various CWE-80 cleansing functions that are able to perform proper output encoding for .NET applications. You can find these methods in our support documentation at this link https://docs.veracode.com/r/Supported_NET_Cleansing_Functions -- just look for methods which have "CWE-80" next to them in the rightmost column. If you include mention of these methods around the areas of your code Veracode has highlighted, the flaws should close out after a re-scan.

Keep in mind with the above recommendation that you want to select an appropriate cleanser method based on the output context in which your application is displaying the HTML. For instance, if the Veracode flaw is reporting a potential XSS issue in your code where the output gets set in an HTML attribute, you want to choose a cleanser function that does HTML attribute encoding over a function that general HTML encoding or URL encoding or JavaScript encoding (etc.). Be aware of the context around how each of your flaws are reported and select the right cleanser accordingly.

Here are some additional resources both inside and outside of Veracode you can consult about the Cross-Site Scripting flaw and how you can address it using other approaches besides output encoding (although output encoding is still the most preferred approach):

• https://www.veracode.com/security/dotnet/cwe-80
• https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html#a7-cross-site-scripting-xss

Please note the supported cleanser function approached mentioned above is the preferred remediation strategy that Veracode static analyzer recognizes. If you and your team decide to go with another XSS prevention strategy as your approach, most likely Veracode static analyzer will not be able to recognize any other XSS mitigation approach. In this case, in order to close out your XSS flaws, please make use of Veracode's mitigation proposal workflow documented here to resolve your XSS flaws this way -> https://docs.veracode.com/r/improve_mitigation . Please be aware that Veracode security consultants do not approve/sign-off on mitigation proposals, this can only be performed entirely within your boundary and team.

Hope you find this helpful. Please let us know if there is anything you need further help understanding here.

Best Regards,

Andrew Bell