CRLF Injection attacks are not as famous as other types of attacks. However, when a CRLF Injection Attack is performed on an application with security vulnerabilities, this attack is equally effective for attackers and can cause great damage to users. Let's see how these application attacks are implemented and what measures you can take to protect your organization.
The meaning of CRLF is "carriage return/line feed", which means to press Enter. These are two ASCII characters, which are respectively placed at 13th and tenth places. CR and LF are the things left behind by the computer terminal or the telex printer. The telex typewriter works like a normal typewriter. At the end of each line, the CR command returns the print header to the left. LF command let the paper move forward one line. Although the terminal era of using paper is over, CR and LF commands still exist, and many applications and network protocols still use these commands as separators.
When searching for security vulnerabilities, attackers did not ignore rarely used CRLF. Attackers can add the CRLF command to a piece of data to change the way the application that accepts the data processes the data, and thus execute the CFRL injection attack.
The most basic example of a CRLF attack is to add a forged record to the record file. That is to say, an application with a security vulnerability writes the content entered by a user to the system record file. Attackers can provide the following inputs:
Testing123MYSQL database error: TABLE partition uption
When the system administrator checks his records in the morning, he may spend a lot of time troubleshooting a non-existent fault. Attackers can use this Trojan Horse to distract administrators from attacking another part of the system.
Imagine that an application receives a file name input by the user and then executes an instruction on that file, such as "ls-.". If the application has a CRLF security vulnerability, attackers can enter the following content:
File.txt rm-rf/
The application with security vulnerabilities will execute the command "ls-a File.txt" and then execute the command "rm-rf /". If the application is a root program, this may be the last command it executes, because all the files in the root partition are deleted.
Consider using a CRFL injection attack to expose the e-mail addresses of a person using a network-based anonymous email system. The email system may work like this: the sender of an email fills in a form with their email address, subject, and information. When the form is submitted to the network server, the network server converts the form to an SMTP email and sends it to the recipient. The sender will never see the recipient's email address. This address is only known to the server.
If the application has the CRLF attack security vulnerability, the sender of the email can create the following topic to corrupt the anonymity of the recipient:
Subject: Peekaboo, I see youBcc: sender@evil.com
When an application with a security vulnerability obtains the data, it adds an unwanted line to the file header of the email and creates a blind copy of the email sent to the sender's email address. In this copy, the "To:" address is invisible, so the recipient's email address is exposed To the sender.
Good programming techniques can be used to avoid CRLF attacks. To protect your applications from CRFL injection attacks, you need to maintain the same vigilance as defending against SQL injection attacks and other types of injection attacks: Never trust the input content! The input content of any source beyond your control must be checked before your application performs operations on the data, delete any characters that do not conform to the expected data type. For example, if you are expecting an email subject line, all the characters in this data should be letters, numbers, and punctuation marks. If your application expects a file name, the data can only contain characters that are valid in the file name. If the programmer simply filters out the CR and LF characters in these two examples, this attack will fail.
User input is a source of "bad characters. However, do not forget to check the input content of other programs you have never written. In many cases, attackers can transfer an injection attack from a vulnerable application to a basic routine. Programmers do not check data in basic routines, because the data is not directly from users. You need to treat any data that you cannot trace to a trusted source as infected data. In this way, you are safe.