CRLF Injection Attack

What is CRLF injection?
The term CRLF stands for Carriage Return (CR, ASCII 13, \r) Line Feed (LF, ASCII 10, \n). These are ACSII characters which display nothing on screen but are very widely used in Windows to indicate an end of line. On Linux/UNIX systems the end of line is indicated by the use of the Line Feed only.

This combination of CR and LR is used for example when pressing "Enter" on the keyboard. Depending on the application being used, pressing "Enter" generally instructs the application to start a new line, or to send a command.

A CRLF Injection attack occurs when a hacker manages to inject CRLF Commands into the system. This kind of attack is not a technological security hole in the Operating System or server software, but rather it depends on the way that a website is developed. Some developers are unaware of this kind of attack and leave open doors when developing web applications, allowing hackers to inject CRLF Commands.

What an attacker can do if your site is vulnerable
Even if attackers find a website open to CRLF Injection, they are limited to how the application structure is built and to how severe the flaw in the system is.

In some types of websites, this flaw may be lethal to the application's security. In other cases, this may just be a small bug with minimal priority. It all depends on whether this flaw allows the user to manipulate the web application.

Example 1 of a CRLF Injection attack
Any kind of user input can be a security issue if not properly validated.

Here is a sample basic log file:

Date UserName Message
25/07/2005-14:23:47 GoodSurfer I perfectly agree!

This log file is perfectly normal, however if a user had to input something like:

I also agree with you..\n25/07/2005-15:00:00 AnotherSurfer What are you talking about!?

The log file would then look like this:

Date UserName Message
25/07/2005-14:23:47 GoodSurfer I perfectly agree!
25/07/2005-14:42:19 BadSurfer I also agree with you..
25/07/2005-15:00:00 AnotherSurfer What are you talking about!?

In this case, since the input is not being properly filtered from the CR and LF characters, the user created a fake entry in the log file.

Example 2 of a CRLF Injection Attack
Many network protocols, including HTTP, make extensive use of the Carriage Return and Line Feed combination of commands since each line used in this protocol is separated by a CRLF. If a user is able to define an unfiltered HTTP header, it poses a risk since the user would then be able to communicate directly to the server, bypassing the application layer.

For example E-mail, News (NNTP) and HTTP headers are all based on the structure of "Key: Value" and each line is defined with a CRLF combination at the end. The "Location:" header is used in HTTP to redirect to another URL and a "Set-Cookie:" header is used for cookies. If these inputs are not properly validated, CR and LF characters can be embedded in the user input, and web scripts can be fooled to do other things than what they were originally constructed for.

If the input is not checked for CR and LF and the script constructs a redirect with the string:

Location: $url%0d%0a

We can redirect to a site while setting a cookie by setting $url (as one string) to:

http://www.i-was-redirected.com/%0d%0aSet-Cookie: Authenticated=yes%0d%0aReferer: www.somesite.com

If an attacker can save the URLs that another user will be redirected to, including cookies with important data, this can be serious.

How to check for CRLF vulnerabilities
The best way to check whether your web site & applications for CRLF vulnerabilities is by using a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for vulnerabilities to CRLF attacks. It will indicate which URLs/scripts are vulnerable so that you can fix the vulnerability easily.

The Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities. For more information & a trial download click here.

Preventing CRLF attacks
The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should "remove everything but the known good data" and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.

Check if your website is vulnerable to attack
Acunetix Web Vulnerability Scanner ensures website security by automatically checking for SQL injection, Cross site scripting, CRLF  and other vulnerabilities. It checks password strength on authentication pages and automatically audits shopping carts, forms, dynamic content and other web applications. As the scan is being completed, the software produces detailed reports that pinpoint where vulnerabilities exist. Take a product tour or download the evaluation version today!

Scanning for XSS vulnerabilities with Acunetix WVS Free Edition!
To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).

Články o bezpečnosti

Keeping Web Hacking at bay with Acunetix - How to avoid a Hacker Attack on your website
Cross Site Scripting - XSS - The Underestimated Exploit
Microsoft UK Events Website Hacked
The JavaScript Engine of Acunetix WVS
PCI Compliance (Payment Card Industry Data Security Standard)
Web Applications: What are they? What of them?
The True Nature of Web Application Security: The Role and Function of Black Box Scanners
Web hacking: An underestimated threat
Ajax security: Are AJAX applications vulnerable to hack attacks?
PHP / SQL Security - Part 6

Více článků

Dokumenty White Paper

Hledání správného skeneru webových aplikací; proč black-box nestačí
The Payment Card Industry Compliance - Securing both Merchant and Customer data.
Web Services - The Technology and its Security Concerns
Are AJAX Applications Vulnerable to Hack Attacks? The importance of Securing AJAX Web Applications
Auditing Your Web Site Security with Acunetix Web Vulnerability Scanner
The Importance of Web Application Scanning
SQL & PHP Security by Andrew J. Bennieston

Další dokumenty White Paper...