Serving Industries Worldwide

Innovative Ways - Satisfied Clientele

OWASP Vulnerability: SQL Injection

iFour Team - 5 Aug 2017

Vulnerable software is threatening to our major sectors of development such as finance, defence, service industry, IT, healthcare, energy generation, manufacturing etc and many more critical infrastructures. As the digital industry is developing and becoming more and more complex, the difficulty of security increases manifolds. And therefore it is a huge risk on our parts to tolerate vulnerabilities that are exposed to risk or which are simple security problems mentioned in the OWASP Top 10 list and software development companies should consider these vulnerabilities while developing software and products.

OWASP is an open community which facilitates to enable organizations to develop, maintain and purchase applications that can be trusted. The objective of the OWASP Top 10 list is to have awareness about the application security and identifying some of the most important risks faced by organizations in today’s world. It gives IT companies the freedom to provide unbiased, cost effective information about the application security that is transparent enough to make valid decisions.

The OWASP Top 10 Vulnerabilities (2013) are as follows:

A1 – Injection

A2 – Cross-Site Scripting (XSS)

A3 – Broken Authentication and Session Management

A4 – Insecure Direct Object References

A5 – Security Misconfiguration

A6 – Sensitive Data Exposure

A7 – Missing Function Level Access Control

A8 – Cross-Site Request Forgery (CSRF)

A9 – Using Known Vulnerable Components

A10 – Invalidated Redirects and Forwards

FINDINGS / HOW CAN THE VULNERABILITY BE COMPROMISED?

The SQL injection has received more attention as this vulnerability can breach the confidentiality of the data in the compromised databases. The loss of confidentiality may result in financial loss, downtime, legal and regulatory penalties, negative publicity of the data or confidential information, databases integrity etc.

This vulnerability may also allow the attacker to gain an advantage to include malicious code in the compromised site/ application. Therefore the visitors can be tricked to install the malicious code or can be redirected to the malicious sites that can exploit many more vulnerabilities into the system.

This can also be compromised to attack the third party sites.

The attacker can log into the system as another fake user or even as an administrator

The attacker can view the private details of the users in the application eg profiles, transaction details etc

The attacker can change the configuration and data of the users/ application

The attacker can modify the structure of the database and modify details

AFFECTED ITEMS AND SEVERITY

Affected items: No alerts in this category.

Severity: High

SQL Injection may result in corruption of data and data loss, denial of service, lack of accountability or sometimes it could even lead to complete host takeover.

DESCRIPTION

A SQL query is one of the ways in which an application can talk with the database. And a SQL injection can occur when an application fails to validate and sanitize the un-trusted data. An attacker can specially craft an SQL command to trick such vulnerable applications asking the database to execute unexpected commands.

SQL injection can be defined as an application’s security weakness that will allow the attacker to control the database of the application and it will let them make changes in the database such as edit, delete data and exploit data to do undesirable things. Such SQL vulnerabilities are preventable but still SQL remains one of the leading web application risks.

RECOMMENDATIONS TO MITIGATE THE RISKS (AVOID/ REDUCE/ TRANSFER THE RISKS)

To prevent user supplied input that contains malicious SQL from affecting the logic of the executed query in the command.

Some of the instructions that the developers need to take are as follows:

1.) Primary Defences:

Option #1: Use of Prepared Statements OR Parameterized Queries

Prepared statements OR Parameterized queries ensure that an attacker is not able to change the intent of a sql query, even if SQL commands are inserted by an attacker or hacker. In the example below, if an attacker were to enter the uID of tommy' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which matched the entire string tommy' or '1'='1.

Here, we have shown examples in Java and .NET but practically all other languages, including PHP, Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the Hibernate Query Language (HQL) have the same type of injection problems (which we call HQL Injection). HQL supports parameterized queries as well, so we can avoid these attacks:

Following is an unsafe HQL Statement
Query unsafeHQLQueryexample = session.createQuery("from Inventory where pID='"+userSuppliedParam+"'");
And following is a safe version of the above query using named parameters Query
safeHQLQueryexample = session.createQuery("from Inventory where pID=:pid");
safeHQLQuery.setParameter("pid", userSuppliedParam);

Option #2: Use of Stored Procedures

Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure has to be predefined in the database and should implement the same functionality as the query defined above.

VB .NET Stored Procedure Example

The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

Option #3: Escaping all User Supplied Input

2) Additional Defences:

Testing for SQL Injection

Method: 1

Using burp suite tool for manual testing the application for the vulnerability named SQL Injection. Turn off the intercept in the “Proxy tab” and then visit the application you want to test in your browser

Now input certain characters in the application to detect SQL Injection. Here, inputting single quote ‘produces an error message.

And if you input double quotes it does not give any custom error message. The reason behind the difference is that the SQL Strings are contained in the single quote delimiters. Therefore when we submit one quote, it breaks the representation of the SQL string and wider the SQL statement. Double quotes are considered as an escape sequence and it represents a literal single quote. Therefore when we submit double quotes in the string it modifies the value of the string and does not break the SQL statement.

Here we do not get any query in the error message. Therefore it implies that SQL injection vulnerabilty does not exist in the application.