This post is part of a multi-post series on web application security threats and their solutions. Please visit my introduction article here to know about more security threats and their solutions.
Introduction
Injection flaws allow attackers to relay malicious code through a web application to another system. These attacks include calls to the operating system via system calls, use of external programs via shell commands, as well as calls to back-end databases via SQL (i.e., SQL injection). Whole scripts written in laguages like perl, python etc can be injected into poorly designed web applications and executed. Any time a web application uses an interpreter of any type there is a danger of an injection attack.
Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.
A report from WhiteHat Security last year reported “83% of websites have had a high, critical or urgent issue”. That is, quite simply, a really high number and it’s only once you start to delve into to depths of web security that you begin to understand just how easy it is to inadvertently produce vulnerable code. Many a times developers are simply either not aware of common security risks at all or they’re familiar with some of the terms but don’t understand the execution and consequently how to secure against them.
There are different types of Injection flaws. SQL injection is the most common, HTML / JavaScript Injection, LDAP injection, XML Injection, XPath Injection, OS command injection
Recommendation
- Input validation is a key for secure applications. In all topics you should consider INPUT VALIDATION. Use an “accept known good” validation strategy.
- Use strongly typed parametrized query APIs with placeholder substitution markers, even when calling stored procedures.
- Enforce least privilege when connecting to databases and other back-end systems.
- Avoid detailed error messages that are useful to an attacker. Don’t forget that attacker accumulate clues from your error messages.
SQL Injection Attack
Description
A successful SQL injection attack enables a malicious user to execute commands in your application’s database by using the privileges granted to your application’s login. The problem is more severe if your application uses an over-privileged account to connect to the database. For example, if your application’s login has privileges to eliminate a database, then without adequate safeguards, an attacker might be able to perform this operation.
Common vulnerabilities that make your data access code susceptible to SQL injection attacks include:
- Weak input validation.
- Dynamic construction of SQL statements without the use of type-safe parameters.
- Use of over-privileged database logins.
Example
Lets consider that we have following table in the application database.
Products
|
Column Name
|
Data Type
|
product_ID
|
Int
|
product_Name
|
varchar(100)
|
supplier_ID
|
int
|
category_ID
|
int
|
unitPrice
|
money
|
stockQuantity
|
int
|
The web application is using following query to display data in a page.
var catID = Request.QueryString[“CategoryID”];
var sqlString = “SELECT * FROM Products WHERE CategoryID = ” + catID;
var connString = WebConfigurationManager.ConnectionStrings [“NorthwindConnectionString”].ConnectionString;
using (var conn = new SqlConnection(connString))
{
var command = new SqlCommand(sqlString, conn); command.Connection.Open();
grdProducts.DataSource = command.ExecuteReader(); grdProducts.DataBind();
}
Suppose the catID required by the SQL query is passed using a query string as follows:
Now, the CategoryID in the query string is untrusted data. We assume it is properly formed and we assume it represents a valid category and we consequently assume the requested URL and the sqlString variable end up looking exactly like this
SELECT * FROM Products WHERE CategoryID = 1
The problem with the construction of this code is that by manipulating the query string value we can arbitrarily manipulate the command executed against the database.
For example:
SELECT * FROM Products WHERE CategoryID = 1 or 1=1
Obviously 1=1 always evaluates to true so the filter by category is entirely invalidated. Rather than displaying only beverages we’re now displaying products from all categories.
This is just a small example of SQL injection the same above query can be used to get more information about other tables and its data. The only thing the hacker will require is some common sense and combination of data which will either pass or fail.
Now just think about the situation where a hacker can use some combinations of names and finds that your table name is Products (which is not a rocket science, any person who know database can find out the name of the table within some time).
Suppose now it modifies the query string as follows:
http://localhost:8000/MyProductList.aspx?CategoryID=1;update products set productname=ProductHacked
SELECT * FROM Products WHERE CategoryID = 1;update products set productname= ProductHacked
You are really hacked now. There is no limit to this and hacker can go beyond our imaginations.
Recommendation
To protect your application from SQL injection, perform the following steps:
- Constrain input. All input must be validated against a white-list of acceptable value ranges.
- Use parameters with stored procedures.
- Use parameters with dynamic SQL. Use Named SQL parameters.
- Use ORM like Entity Framework, N Hibernate, LINQ to SQL etc
- Applying the principle of least privilege
In information security, the principle of least privilege, requires that in a particular abstraction layer of a computing environment, every module, a process, a user or a program must be able to access only such information and resources that are necessary to its legitimate purpose.
HTML / JavaScript Injection Attack
Description
- JavaScript injection attack can be used to perform a Cross-Site Scripting (XSS) attack. In a Cross-Site Scripting attack, you steal confidential user information and send the information to another website.
- JavaScript injection attack can be used to steal the values of browser cookies from other users.
- If sensitive information such as passwords, credit card numbers, or social security numbers is stored in the browser cookies, then a hacker can use a JavaScript injection attack to steal this information.
Please refer to thisarticle to know more about XSS.
XML Injection and XPath Injection
XML Injection is an attack technique used to manipulate or compromise the logic of an XML application or service. The injection of unintended XML content and/or structures into an XML message can alter the intend logic of the application. Further, XML injection can cause the insertion of malicious content into the resulting message/document. An example of XML injection to include insertion of full XML structures. Consider this example XML document:
joepublic
r3g
0
joepublic@example1.com
janedoe
an0n
500
janedoe@example2.com
If the attacker were to inject the following values for a new user ‘tony’:
Username: alice
Password: iluvbob
0hacker@exmaple_evil.net
Then the resulting XML document would be:
joepublic
r3g
0
joepublic@example.com
janedoe
an0n
500
janedoe@example2.hmm
alice
iluvbob
500
alice@exmaple3.comHacker l33tist0
hacker@exmaple_evil.net
A successful attack would allow an attacker to steal the entire database, including all sensitive data, and log in with administrative privileges in the application. This is one of the most high risk vulnerabilities an application can have.
Preventing XML Injection
- This can be prevented in a similar way to SQL Injection. The best way is to carefully sanitize user input. Any data received from a user should be considered unsafe. Removing all single and double quotes should remove most types of this kind of attack.
- Beware that removing quotes can have side effects, such as when usernames might contain valid quotes. Imagine common names such as O’Malley, which contains a legitimate quote and may be input on a name request form. In these cases, the input should be escaped, often by adding a \ in front of quotes. Check with your specific library and XML software for the proper syntax.
0 Comments