Many online attacks try to fool a server with dirty user input. They use characters that aren't supposed to be there, in the hope that the server will accept them. If it does, it could parse the input incorrectly, directing the software to do things it shouldn't and breaking down website security.
SQL injection comes to people's minds first, but it's not the only example. A quotation mark and a semicolon in the right place will trick an unprotected database server into executing commands from the user input. Another type, not as well known, is CRLF injection. It puts line endings into the input, sometimes doing even worse harm than SQL injection. The line ending for Internet command streams is most often a carriage return followed by a line feed, which is how the attack gets its name. In some cases, the line ending is just a carriage return or a line feed, but the principle is the same.
CRLF injection and HTTP response splitting
The protocols which use CRLF to delimit commands include MIME (email), FTP, and HTTP. The favorite target for injecting line endings is HTTP headers. A blank line (two CRLFs in a row) marks the end of the headers and the start of the body. This may seem like a very fragile way to construct data on which people's livelihoods may depend, but it dates from the early, trusting days of the Web.
The reason for using both a CR and an LF is the use of teletype terminals in the early days. A carriage return brought the print element back to the start of the line, and a line feed advanced the platen by one line. That's no longer necessary, but it's still the standard.
The use of the technique in HTTP headers is called HTTP response splitting. What ought to have been one line is split into two. The second line is any header which the attacker wants to introduce. It can be a blank line, causing the server to ignore all subsequent headers.
The technique is to put content with a line break into a user input, where the server will use it in a header. For example, a server might accept a name from the user and put it into a cookie value. If the "name" contains a line break, the part following could become the next header. For example:
The opportunities for "evil things" are limited only by an evil imagination. Here are some scenarios:
- The injection includes a Content-Length header followed by a blank line and HTML content. This completely replaces the intended output with whatever the attacker crafts. The Content-Length header makes the browser stop reading when it gets the specified number of characters, so the original content is ignored.
- Injecting a Location or Content-Location header will replace the content with data from a different URL.
- Overriding headers such as Cross-Origin-Resource-Policy, Content-Security-Policy, or X-XSS-Protection reduces the security of a page.
- Any header which incorporates user input could be vulnerable. Plausible ones include From, Cookie, Content-Language, and Content-Type.
Injection of HTTP headers is usually just the first step in a multi-part attack. It could set up a lookalike page to steal passwords, a script to wreak havoc or an infected file to download. It could weaken the page's protection so that cross-site scripting (XSS) or another attack won't be blocked. If the server uses a weak authentication mechanism, it might be able to impersonate an authorized user.
Other types of injection
Some Web applications construct shell scripts to carry out tasks. If they accept user input for command parameters, they're potentially vulnerable to CRLF injection. Inserted commands could delete files or change their protection, to name two of the many possibilities. Web application designers need to be very careful whenever they generate shell scripts.
User input sometimes gets into log files. CRLF injection could generate bogus log entries. This isn't as obviously harmful as affecting HTTP headers or scripts, but it could make the log confusing, slowing down administrators when they're trying to discover the nature of an ongoing attack. Web application designers are less likely to think of this case since it's taken for granted that logs will be somewhat chaotic.
Protection by filtering and sanitization
All user input needs to be treated as untrusted data. The server needs to check it for any dirty tricks before using it. JavaScript checking isn't enough. An attacker can turn off JavaScript or construct POST requests directly.
Depending on the situation, requests should be filtered, sanitized, or both. Filtering rejects inputs that look wrong and don't allow the request to take place until the user fixes them. Sanitization removes or changes potentially dangerous parts of the input.
It's a mistake to write custom code for this purpose. Attackers have many ways to bypass the obvious safeguards. They can use backslash escapes, HTML entities, hex encoding, and so on. The best approach is to use a good framework or code library. The best ones have been tested against the most devious forms of obfuscation. Criminals will have a hard time getting around them.
Protection with a Web Application Firewall
One kind of protection isn't enough in today's Internet environment. True website security requires a multi-layered approach. Even if the application does everything possible to stop CRLF injection and similar threats, it's better to catch most of the attempts as they're being made.
A Web Application Firewall (WAF) provides that additional layer of protection. An HTTP request or response which an injection has compromised will present suspicious features that the WAF can detect. It can then block the request or issue a warning. These signs include:
- Duplicate headers
- Content-Length which is shorter than the actual content
- HTTP headers in the HTML document
- Redirection to an unauthorized host
- Malformed or excessively long data fields
Quttera's ThreatSign anti-malware platform includes the Quttera WAF. It recognizes many kinds of threats directed at the Web server and blocks them. Every website on the Internet is constantly being probed for weaknesses. Using Quttera Web Application Firewall in conjunction with the best website security practices will stop the large majority of the attempts.