What are injections:
Apart from the scary needles which we see in clinics and sometimes use as tools to scare kids, the term “Injection” means something else in Cyber world.
What are Injection Attacks?
Injection attacks refer to a broad class of attack vectors that allow an attacker to supply untrusted input to a program, which gets processed by an interpreter as part of a command or query which alters the course of execution of that program.
Injection attacks are amongst the oldest and most dangerous web application attacks. They can result in data theft, data loss, loss of data integrity, denial of service, as well as full system compromise.
Injection is a major problem in web security. It is listed as the number-one web application security risk in the OWASP Top 10 — and for good reason. Injection attacks, particularly SQL injection [SQLi] and Cross-site Scripting [XSS], are not only very dangerous, but they are also very widespread, especially in legacy applications.
Types of Injection Attacks:
There are mainly 9 types of injections classified based on….:-
1. Code Injection: Code injection is the malicious injection or introduction of code into an application. The code introduced or injected is capable of compromising database integrity and/or compromising privacy properties, security and even data correctness. It can also steal data and/or bypass access and authentication control. Code injection attacks can plague applications that depend on user input for execution.
Code Injection differs from Command Injection. Here an attacker is only limited by the functionality of the injected language itself. For example, if an attacker is able to inject PHP code into an application and have it executed, he is only limited by what PHP is capable of.
Code injection vulnerabilities range from easy to difficult-to-find ones. Many solutions have been developed for thwarting these types of code injection attacks, for both application and architecture domain. Some examples include input validation, parameterization, privilege setting for different actions, addition of extra layer of protection and others.
Example:
The following is an example in PHP that is vulnerable to Code Injection.
/**
* Get the code from a GET input
* Example - //example.com/?code=phpinfo[];
*/ $code = $_GET['code'];
/** * Unsafely evaluate the code
* Example - phpinfo[];
*/
eval["\$code;"];
In the above example, an attacker could make the following request to execute arbitrary PHP code. In this case, a PHP info page will be displayed
//example.com/?code=phpinfo[];
Potential Impact of Code Injection: Full System Compromise.
2. CRLF Injection: When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP headers and the actual website content. The HTTP headers and the HTML response [the website content] are separated by a specific combination of special characters, namely a carriage return and a line feed. For short they are also known as CRLF.
The server knows when a new header begins and another one ends with CRLF, which can also tell a web application or user that a new line begins in a file or in a text block.
CRLF injection is a software application coding vulnerability that occurs when an attacker injects a CRLF character sequence where it is not expected. When CRLF injection is used to split an HTTP response header, it is referred to as HTTP Response Splitting. CRLF injection vulnerabilities result from data input that is not neutralized, incorrectly neutralized or otherwise un-sanitized.
Attackers provide specially crafted text streams with CRLF injections in order to trick the web application to perform unexpected and potentially harmful actions, ranging from medium to high severity. Attackers exploit the CRLF injection vulnerability by injecting CRLF sequences in order to split a text stream to embed text sequences that the web application is not expecting. These unexpected CRLF injections can result in a security breach and cause material harm.
Example:
Below is one of the most basic example of a CRLF attack: Adding fake entries into log files. Suppose a vulnerable application accepts un-sanitized or improperly neutralized data and writes it to a system log file. An attacker supplies the following input:
Hello, WorldDATABASE ERROR: TABLE CORRUPTION
Because this error is fake, a sys-admin may waste a lot of time troubleshooting a non-existent error. An attacker could use this type of Trojan to distract the admin while attacking the system somewhere else.
Another way to illustrate how CRLF injections can cause severe harm is through an application that accepts a file name as user input and then executes a relatively harmless command on that file, such as "ls –a ." If the application is vulnerable to CRLF injection because of improperly neutralized or un-sanitized data input, an attacker could provide the following input:
fname/bin/rm -rf /
This CRLF injection attack could wipe out the entire file system if the application were running with root privileges on a linux/unix system.
Potential Impact of CRLF Injection: Cross Site Scripting
3. Cross Site Scripting:Cross-Site Scripting [XSS] attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
Example:
In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload.
In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.
The following server-side pseudo-code is used to display the most recent comment on a web page.
print “”
print “Most recent comment
”
print database.latestComment
print “”
The above script is simply printing out the latest comment from a comments database and printing the contents out to an HTML page, assuming that the comment printed out only consists of text.
The above page is vulnerable to XSS because an attacker could submit a comment that contains a malicious payload such as:
doSomethingEvil[];
Users visiting the web page will get served the following HTML page.
Most recent comment
doSomethingEvil[];
When the page loads in the victim’s browser, the attacker’s malicious script will execute, most often without the user realizing or being able to prevent such an attack.
Potential Impact of XSS:
— Account impersonation
— Defacement
— Run arbitrary JavaScript in the victim’s browser
4. Email header Injection: It is a common practice for websites to implement contact forms which in-turn send emails to an intended recipient of the message by a legitimate user. Most of the time such a contact form would set SMTP headers such as From and Reply-to to make it easy for the recipient to treat communication from the contact form just like they would any other email. Unfortunately, unless the user’s input is validated before being inserted into SMTP headers, the contact form might be vulnerable to Email Header Injection [also referred to as SMTP header injection]. This is because an attacker may be able to inject additional headers into the message, thereby instructing the SMTP server to carry out different instruction than intended.
Example:
The following PHP code is an example of a typically contact form vulnerable to Email Header Injection. The following code takes the name and email address provided by a website visitor and prepares a list of headers for the email.
The From header is used so that the email’s recipient will know whom the email’s author is. The Reply-To header allows the email’s recipient to reply back to the person who sent the email via the reply button in their email client.
A typical genuine POST request would be as follows:
POST /contact.php HTTP/1.1
Host: www.example.com
name=Joe Bloggs&replyTo=&message=Example message
An attacker could abuse this contact form by sending the following POST request.
POST /contact.php HTTP/1.1
Host: www.example.com
name=Attacker\nbcc: &replyTo=&message=Attacker message
In this example, an attacker is inserting a newline [\n on most UNIX and Linux systems, \r\n on Windows systems] and appending a bcc SMTP header containing additional email addresses to whom the SMTP server will deliver the email to in BCC.
An attacker could use such tactics to send large numbers of messages anonymously, or even send phishing emails where the recipient believes these messages are originating from a trusted source. It’s also worth noting that this vulnerability is not limited to PHP; it can potentially affect any application that sends email messages based on arbitrary user input.
Potential Impact of Email Header Injection:
— Spam relay
— Information disclosure
5. Host header Injection:
It is common practice for the same web server to host several websites or web applications on the same IP address. This why the host header exists. The host header specifies which website or web application should process an incoming HTTP request. The web server uses the value of this header to dispatch the request to the specified website or web application. Each web application hosted on the same IP address is commonly referred to as a virtual host. So what constitutes a host header attack?
What happens if we specify an invalid Host Header? Most web servers are configured to pass the unrecognized host header to the first virtual host in the list. Therefore, it’s possible to send requests with arbitrary host headers to the first virtual host.
Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations this header will rewrite the value of the Host header. Therefore it’s possible to make the following request.
GET / HTTP/1.1
Host: www.example.com
X-Forwarded-Host: www.attacker.com
Many web application rely on the HTTP host header to understand “where they are”. Unfortunately, what many application developers do not realize is that the HTTP host header is controlled by the user. As you might already know, in application security user input should always be considered unsafe and therefore, never trusted without properly validating it first.
Example:
The use of the host header is especially common in PHP web applications, however, it’s certainly not a problem endemic to PHP web applications. The PHP script in the following example is a typical and dangerous use of the host header.