Hello @vsm922275 (Community Member)​ ,

Veracode static analyzer reports CRLF injection flaws for both web applications and APIs wherever it finds that the app or API in question accepts tainted, untrusted input from outside the code itself and uses this in a context where unsafe interpretation of CRLF sequences could lead to a injection security issue. Examples of data that can originate from outside your code can include HTTP requests, reading from a database, reading from a file on a server, etc. -- basically any external source where the input handled is not part of the scanned source code upload.

There are primarily two main cases where CRLF injection is of concern. The first case happens wherever the .NET API uses and writes the untrusted input as part of an HTTP response header -- failing to validate, encode or sanitize this can result in an attack known as "HTTP Response splitting" , which gives attackers the ability to manipulate the HTTP responses returned by your application. This can lead to undesired behaviors permitted by your API depending on how it is used or consumed by other systems and services in your API runtime environment. This flaw is reported in Veracode with the label "CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Response Splitting)".

The second case happens whenever the API uses and write untrusted input to a server log file through a logger statement. By failing to validate, encode or sanitize this, attackers will have the ability to hijack intended logging behavior set forth in your application in order to insert fraudulent logs and cover up tracks of any bad behaviors performed inside the application. This flaw is reported in Veracode with the label "CWE-117 Improper Output Neutralization for Logs". There is also a third type of label related to CRLF injection with the label "CWE-93 Improper Neutralization of CRLF Sequences (CRLF Injection)" that is used to report other kinds of general cases that do not map to any of the first two cases but where un-sanitized CRLF sequences could still lead to a secure data handling issue. Most likely the flaw you are seeing reported for your .NET API maps to any of these three CWE categories.

Regardless of what specific type of CRLF injection flaw your API received from the Veracode scanner, the process to fix and address these flaws is the same across all of these CWEs. We suggest you apply any of the following recommendations below when responding to these types of flaws:

1. Use and correctly apply a supported and recognized cleansing encoder function for .NET developed applications and APIs listed at https://docs.veracode.com/r/Supported_NET_Cleansing_Functions . Pick any listed function that has CWE-93, CWE-113, and CWE-117 next to it and apply this to the tainted, untrusted input variable that Veracode has highlighted in the details of your flaw -- this can be determined by expanding the details of the flaw in the Triage Flaws view > and looking at either the "Attack Vector" or "Description" section of the flaw. We recommend applying the cleanser as closely as possible to the actual line of code highlighted as part of the flaw in order to make it easier for Veracode analyzer to see that it is getting set and applied properly. Though many encoders are listed here that can cleanse CRLF from your inputs, we recommend choosing a URL focused encoder library over other types of HTML or HTML attribute based encoders. If you do this correctly and re-scan your code, the flaw should resolve at that point with no further input or involvement needed by your team.
2. Ensure that you have some other custom validation, encoding or sanitization scheme in place that also guarantees safe handling of any CRLF characters that could come in as part of the input. For example, you can choose to add a helper validation method that looks out for any occurrence of `\r` and `\n` characters in the input field and replaced these patterns with something else (or remove them entirely). You can also choose to enable and enforce any CRLF checks as part of the framework used to build your API and/or underlying runtime environment where your API operates. Please note that with this option Veracode static analyzer cannot recognize and resolve any flaws mitigated through a custom strategy that is not option 1 above. Here in order to resolve the flaw, you will need to propose and submit a mitigation proposal and get this approved by your security team. Instructions on how to start the mitigation proposal process in Veracode is documented at https://docs.veracode.com/r/improve_mitigation and https://community.veracode.com/s/knowledgeitem/mitigations-part-1-what-is-a-mitigation-MCKTIDIWZQ3RBENLRUYP4KSZW3SQ . Please make sure that you test and validate any custom mitigation strategy to make sure it works properly for your API's use case.

Finally, here are some additional references and resources on this subject that you can have a look over in order to understand this issue and how to properly fix it. Most of these guides single out CWE-117 in particular, but as said earlier, the remediation focused sections of these guides can also be applied to the other CRLF injection scenarios highlighted above.

• https://www.veracode.com/security/dotnet/cwe-117
• https://community.veracode.com/s/article/How-to-Fix-CWE-117-Improper-Output-Neutralization-for-Logs
• https://community.veracode.com/s/videotutorial/crlf-injection-tutorial-MC4HDZ7LRNX5FEVLCAL5JCB4EP4Q (this is a video tutorial to walk through CRLF using vulnerable Java + .NET application examples)

Hopefully this helps get you started in the right direction towards fixing these kinds of findings in your Veracode scan report. If there's anything more we can help clarify here, please let us know. 

Best Regards,

Andrew