Request for Adding CRLF Injection Check to ASVS

[ImanSharaf]

I noticed that the current version of the Application Security Verification Standard (ASVS) does not include a check for CRLF Injection vulnerabilities. CRLF Injection is a type of injection attack that involves inserting CRLF characters (carriage return and line feed) into an HTTP request or response to manipulate the message's headers or body. This can lead to a range of security issues, such as HTTP response splitting, cross-site scripting (XSS), and cross-site request forgery (CSRF).

Given the severity and prevalence of CRLF Injection attacks, I recommend that ASVS includes a specific check for this vulnerability. This would help organizations to identify and mitigate CRLF Injection vulnerabilities in their web applications, and ensure that their applications are secure against this type of attack.
A sample check could be this one:

Verify that input validation and encoding of HTTP request and response headers and bodies is performed to prevent CRLF Injection attacks. Verify that the application does not allow CRLF characters (i.e. '\r', '\n', '%0d', '%0a') to be injected into HTTP headers and bodies.

[elarlang]

It's not in special spotlight, but it is covered by 5.3.1:

#	Description	L1	L2	L3	CWE
5.3.1	[MODIFIED] Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, CSS, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4)	✓	✓	✓	116

If to go to separate requirement, then it should be more abstract to cover also emails etc, like:
https://security.elarlang.eu/cve-2016-4803-dotcms-email-header-injection-vulnerability-full-disclosure.html

[ImanSharaf]

What do you think about this one? Verify that input validation and encoding of HTTP requests, responses, emails, and other relevant inputs is performed to prevent CRLF Injection attacks. Verify that the application does not allow CRLF characters (i.e. '\r', '\n', '%0d', '%0a') to be injected into HTTP headers, email headers, and other message bodies.

[jmanico]

I do not know if this is all correct information but I really like the level of precision

[jmanico]

The other issue is that many (most) frameworks handle this automatically. Do you know where this defense is needed and where this is automatically protected in frameworks?

[ImanSharaf]

Hi @jmanico , we can find CRLF injection write-ups in well-known companies, for example:
1- $6000 with Microsoft Hall of Fame | Microsoft Firewall Bypass | CRLF to XSS
2- Breaking GitHub Private Pages for $35k
3- Bypassing Akamai’s Web Application Firewall Using an Injected Content-Encoding Header

[tghosth]

If to go to separate requirement, then it should be more abstract to cover also emails etc, like:
https://security.elarlang.eu/cve-2016-4803-dotcms-email-header-injection-vulnerability-full-disclosure.html

@elarlang is this vulnerability covered by this:

#	Description	L1	L2	L3	CWE
5.2.3	Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.	✓	✓	✓	147

[tghosth]

@ImanSharaf @jmanico @elarlang

I think I agree with @elarlang that this requirement seems to cover CRLF in HTTP headers

#	Description	L1	L2	L3	CWE
5.3.1	[MODIFIED] Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, CSS, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4)	✓	✓	✓	116

I think overall this requirement needs some work but technically it is covered.

Any further comments @ImanSharaf or @jmanico ?

[elarlang]

Yes, my example is covered by 5.2.3 but also matches to CRLF injection topic.

From ASVS side the question is - is CRLF injection widespread and critical enough to have separate requirement for giving it extra attention or are we happy to have it covered by 5.3.1?

[jmanico]

I have not seen any significant CLRF

Yes, my example is covered by 5.2.3 but also matches to CRLF injection topic.

From ASVS side the question is - is CRLF injection widespread and critical enough to have separate requirement for giving it extra attention or are we happy to have it covered by 5.3.1?

I am not sure of this either, but ImanSharaf seems to give us good recent information that CLRF is found recently in some rather large bug bounties...

[ImanSharaf]

Thank you for your response and for pointing out that ASVS 5.3.1 does technically cover CRLF Injection in HTTP headers. However, I would like to express my concern that the current wording of 5.3.1 might not explicitly highlight the importance of testing for CRLF Injection attacks. As a result, testers might inadvertently overlook this specific attack vector when performing security assessments.

[elarlang]

Compared to other relatively exotic issues for new requirements, CRLF is actually exists and I think it makes sense to have more attention to it. Should it be in separate requirement or clearly said out in some other requirement is another question.

Maybe we need to split up this monster list of technologies from 5.3.1 and then those separate requirements can fit more examples.

[tghosth]

You said you were ok with it here ;)

I agree that we should split this requirement up slightly.

I opened #1589 and I am going to close this one for now.

[elarlang]

For the record - "I'm ok with it" was for content as "I'm ok with it (as it's technically correct)" and does not mean it can not be improved :)