What Are CRFL Injection Attacks?
The CRLF injection attack is as its name suggests, a type of injection attack which has a medium severity rating. The acronym stands for Carriage Return (\r) Line Feed (\n); with ‘Carriage Return’ denoting to the end of a line and ‘Line Feed’ referring to a new line.
When a user browses a website and clicks for specific content, the server provides the requested web content with the HTTP headers. These headers and contents are divided by the defined combination of CR and LF. The job of CRLF is to ensure that the server recognises where a new header begins or ends.
When an attacker imposes a CRLF injection attack, the attacker injects CRFL characters into an input field to trick the server into believing that an object has been terminated and a new one has begun. This attack occurs if the web application does not sanitise CRLF characters from the user input.
The purpose behind using these attacks is to escalate cross-site scripting attacks, web cache poisoning and cache-based defacement.
Most Common Uses of CRLF Injection Attacks
The two most common uses of CRLF injection attacks are the following:
- Log Poisoning – Where the attacker changes log file entries by entering an end of a line and an additional line to hide other attacks or mislead system administrators.
- HTTP Response Splitting – Where the attacker adds HTTP headers to HTTP responses (to perform cross site scripting attacks).
Impacts of CRLF injection attacks
Attackers typically perform CRLF injection attacks to set fake cookies, inject scripts and steal CSRF (Cross Site Request Forgery) cookies. If successful, the attacker(s) will then be able to deactivate inbuilt security functions, enabling them to cause further damage.
Cross Site Scripting
This attack is a type of injection attack which is carried out by injecting malicious scripts into trusted websites. These scripts are written in the same format of a browser side script to trick the browser into believing it is safe.
The attacker can also send these malicious scripts to the target user whose browser will perform the script, believing it to be from a trusted source. Once performed, the malicious script can then access cookies, session tokens or other sensitive functions and information.
Cookie Injection
This attack involves injecting malicious codes into browsing cookies. To do this, the attacker will need access to the user’s accounts. The most common attempt to ‘poison’ the cookies is by using SQL commands.
Phishing Attacks
One of the purposes behind CRFL injection attacks include redirecting users to malicious websites to steal their personal details. The main purpose behind phishing attacks and almost every cybersecurity attacks is financial gain for the attacker(s).
Session Fixation
This attack involves an attacker attempting to exploit a vulnerability by focusing on the target user’s session identifier. The majority of session fixation attacks are web based and are dependant on session identifiers being approved by URLS or POST data.
HTTP Header Injection
This is a type of web application vulnerability which occurs when Hypertext Transfer Protocol headers are created based on user input. This attack has a knock-on effect as if successful, the attacker can then enforce HTTP response splitting, session fixation, cross-site scripting and other malicious redirections.
Web Cache Poisoning
This occurs when the attacker exploits the actions of the targeted web server and its cache so that a harmful HTTP response is sent to the server’s users.
Log Poisoning
Log types come in many different forms including debug logs, access logs, error-based logs, user logs and system logs. Much of the global data is dependant on logs in modern times.
Log poisoning can be a result of untrusted data being entered into a log file without validation.
Detection and Mitigation
Although CRLF injections may seem less serious compared to other forms of cybersecurity attacks, they should not be overlooked. Attackers use CRLF injections to intensify more serious, exploitative web-based attacks. Detecting such attacks is relatively easily. Running vulnerability scan is all that needs to be done.
CRLF injection vulnerabilities are for the most part, automatically mitigated by the web frameworks. In the case of a vulnerability not being mitigated, the steps that need to be taken are simple.
You can choose the following options:
- Modify your code to ensure that the content provided to the user is not used in the HTTP stream.
- Remove newline characters before moving content to the HTTP header.
- Encrypt the data you put into the HTTP headers.
Preventative Measures
CRLF vulnerabilities tend to be automatically mitigated by web frameworks however, there are further preventative measures that can be taken to reduce the likelihood of a successful attack.
These measures include:
- Being wary of all client supplied data.
- Sanitising data intended to be a response.
- Removing the CRLF before logging the necessary data.
- Disabling unused headers.
- Ensuring that the system is regularly fitted with newly released patches to resolve potential underlying vulnerabilities.
- Having in place SIEM practices so that alerts can then be monitored and responded to.
