Injection Flaws

Introduction

In this article, we are going to look at other injection flaws. We are going to look at the different types of injections, how they affect the web applications, and how they can be countered. There are various kinds of injection flaws out there that serve different purposes.

Injection flaws are a group of attack vectors aimed at causing malfunction or compromise the primary purpose of any given web application or website. These attacks are implemented using user input to a system. Attackers make use of various tools to incapacitate an application, thereby disrupting the application’s purpose or getting unauthorized access to the application. An attacker may end up having access to confidential information or interrupting the integrity stored in an application’s database. Largely, this causes disrepute between the organization and its customers, resulting in great financial loss.

Types of Injection Flaws

In this article, we are going to look at the following types of Injection Flaws:

SQL Injection
Command Injection
HTML Injection
Code Injection
XML Injection. All these are different types of attacks that attackers use to manipulate websites/web applications using input data.

SQL Injection

This is a form attack that attackers use with the help of SQL statements, i.e. they use input controls to supply SQL statements that may reveal sensitive information or delete sensitive information, thus negatively impacting the legit users of the system. It is also known as SQLi.

There are different types of SQL injections, including:

In-band Injection (Classic)

Error-based Injection
Union-based Injection

Inferential Injection (Blind)

Boolean-based Injection
Time-based Injection

Out-of-band Injection

The three types of injection have a common implementation, which is the Structured Query Language. Attackers use this database language in input controls to gain unauthorized access to web applications, thus compromising their integrity and confidentiality.

Example

By supplying a query like this in the input field, an attacker may gain access to the database information and use it to manipulate other statements such as DROP TABLE, etc.

'OR '1'='1';Select @@version--'

After supplying this, an attacker will get knowledge about the database, as shown below:

SQL Injection is a common attack vector and normally attacks those applications with SQL statements that use a dynamic way of supplying their parameters.

SQL Injection can be prevented by strongly validating input fields such that user input is filtered before it is submitted or by the use of online software tools that scan your web application for injection vulnerabilities. Other prevention techniques include using password encryption and managing the error messages revealed to users so that they only show that there has been an error, but the internal details are not revealed.

Example of validation:

Command Injection

Command Injection is when the attacker injects operating system commands on a user input field. The attacker may inject malicious commands to the host's operating system and get sensitive information from the webserver.

Command Injection attacks are common in languages such as Perl or PHP. These languages encourage programmers to reuse operating system binaries. Command Injection requires the attacker to manipulate script parameters that execute arbitrary system commands. These problems occur when scripts execute external commands using input parameters to construct command lines, but fail to filter the input data.

Example in PHP:

http://www.attacker.com/view_user.php?username=ivanr;cat%20/etc/pwd

It will display the contents of the PWD file on the server. This means that the attacker will have compromised the host operating system and he may proceed to start a Telnet server and log into the server as a user, try to gain root access, try to download and compile the source code of the application, and execute any binary on the server.

Another common Command injection attack is through the email sending in form-to-email scripts. These scripts are usually written in Perl. They accept data from an HTTP POST request and they construct the message and use sendmail.

# send email to the recpient

open(MAIL, "|/usr/lib/sendmail $email");

print MAIL "Thank you for contacting us.\n";

close MAIL;

The $emailparameter is not checked for any malicious contents in the code the attacker may terminate the address using a semi-colon and execute malicious commands on the host operating system.

http://www.attack.com/[email protected];rm%20-rf%20/

Command Injection can be prevented by:

Avoiding EXEC on the operating system if avoidable, let the application run its commands.
Using validation on all untrusted user inputs.

HTML Injection

HTML Injection attack allows the injection of valid HTML code, usually via a parameter value and they put their malicious content on the same page. Usually, this is used to gain trust from an unsuspecting user. HTML Injections are purely client-side they attack the user, not the server. They may come in the form of a login form similar to the one on the original application. The attacker may craft a link and send mail to an unsuspecting user which pops the form with valid HTML controls.

The user may log in unsuspectingly and by so doing they will send their login credentials to the attacker thus the attacker will have access to their account and the unsuspecting user will not know about the injection until the attacker does something malicious with the account in question.

Besides account credentials, the attacker may simply use HTML injection to spoil the reputation of the website or web application by adding some malicious content on the original page.

XML Injection

XML Injection is an attack technique that makes use of XML applications or services. The injections are meant to alter the logic of the application. XML injection can cause the insertion of malicious data in the resulting documents.

Example

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>johndoe</username>
<passwd>ryhnjghr</passwd>
<userid>2
<userid/>
<email>[email protected]</email>
</user>
<user>
<username>janedoe</username>
<passwd>wxyz</passwd>
<userid>3
<userid/>
<email>[email protected]</email>
</user>
</users>

The attacker may choose to add the following values:

Username: james

Password: 1234

E-mail: [email protected]</email></user><user><username>Attacker</username><passwd>12345</passwd><userid>2</uid><email>[email protected]</email>

Then the resulting XML document would be:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>johndoe</username>
<passwd>ryhnjghr</passwd>
<userid>2</userid>
<email>[email protected]</email>
</user>
<user>
<username>janedoe</username>
<passwd>wxyz</passwd>
<userid>3</userid>
<email>[email protected]</email>
</user>
<user>
<username>james</username>
<passwd>12345</passwd>
<userid>2</userid>
<email>[email protected]</email>
</user>
<user>
<username>Attacker</username>
<passwd>12345</passwd>
<userid>2</userid>
<mail>[email protected]</mail>
</user>
</users>

Notice that in this example, the attacker may be inserted with userid 2 and in most cases, in XML the second ID instance overrides the first. Thus, XML Injection can be used to alter documents and deter their integrity through this technique.

Conclusion

There are several other injection flaws not discussed in this article. Injection flaws vary from type to type but essentially their main objective is not compromised or manipulate web activity. Injection flaws remain a developer scare and organizations and developers work tirelessly to try and mitigate these practices.