SQL injection attack and defense notes

Tuesday, 5 June 2018

SQL injection vulnerabilities most commonly occur when the Web application developer does not ensure that values received from a Web form, cookie, input parameter, and so forth are validated or encoded before passing them to SQL queries that will be executed on a database server.

If an attacker can control the input that is sent to an SQL query and manipulate that input so that the data is interpreted as code instead of as data, he may be able to execute code on the back-end database.

Without a sound understanding of the underlying database that they are interacting with or a thorough understanding and awareness of the potential security issues
of the code that is being developed, application developers can often produce inherently insecure applications that are vulnerable to SQL injection

What is the impact of an SQL injection vulnerability?
A: This depends on many variables; however, potentially an attacker can manipulate data in the database, extract much more data than the application should allow, and possibly execute operating system commands on the database server

Is SQL injection a new vulnerability?
A: No. SQL injection has probably existed since SQL databases were first connected to Web applications. However, it was brought to the attention of the public on Christmas Day 1998.

Can Web sites be immune to SQL injection if they do not allow the quote character to be entered?
A: No. There is a myriad of ways to encode the quote character so that it is accepted as input, and some SQL injection vulnerabilities can be exploited without using it at all. Also, the quote character is not the only character that can be used to exploit SQL injection vulnerabilities; a number of characters are available to an attacker, such as the double pipe (||) and double quote (“), among others.

Q: My application is written in PHP/ASP/Perl/.NET/Java, etc. Is my chosen language immune?
A: No. Any programming language that does not validate input before passing it to a dynamically created SQL statement is potentially vulnerable; that is, unless it uses parameterized queries and bind variables.

Learn more on => SQL injection Contd......
Cross Site Scripting => Click on me :)

Finding SQL Injection
The Web browser is a client acting as a front-end requesting data from the user and sending it to the remote server which will create SQL queries using the submitted data. Our main goal at this stage is to identify anomalies in the server response and determine whether they are generated by an SQL injection vulnerability.

Testing by Inference
There is one simple rule for identifying SQL injection vulnerabilities: Trigger anomalies by
sending unexpected data. This rule implies that:
■■ You identify all the data entry on the Web application.
■■ You know what kind of request might trigger anomalies.
■■ You detect anomalies in the response from the server.

The two most method are GET and POST
Now Get send everything in URL
for exampe :- GET /search.aspx?text=lcd%20monitors&cat=1&num=20 HTTP/1.1
This kind of request sends parameters within the URLs in the following format:

POST = POST method is basically used when u fill the form, the value are sent at the bottom of the request

POST /contact/index.asp HTTP/1.1

Content-Length: 129

Manipulating Parameter
For example, u have an URL

The showproducts.php page receives a parameter called category. we don't have type anything but click on link and u r redirected

but if u change http://www.victim.com/showproducts.php?category=attacker

you get SQL error
In the preceding example, we sent a request to the server with a non-existent category
name. The response from the server was as follows:
Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /var/www/victim.com/showproducts.php on line 34

Learn more on => SQL injection Contd......

Another interesting test you can conduct to identify vulnerabilities in Microsoft SQL Server and Oracle is to send the following two requests to the Web server:
The MySQL equivalent is:
http://www.victim.com/showproducts.php?category=bi' 'kes

If the result of both requests is the same, there is a high possibility that there is an SQL injection vulnerability.

SQL injection vulnerabilities occur for two reasons:
■■ Lack of user input sanitization
■■ Data and control structures mixed in the same transport channel

handled as a result of one of the following:
The SQL error ■■ is displayed on the page and is visible to the user from the
Web browser.
■■ The SQL error is hidden in the source of the Web page for debugging purposes.
■■ Redirection to another page is used when an error is detected.
■■ An HTTP error code 500 (Internal Server Error) or HTTP redirection code 302
is returned.
■■ The application handles the error properly and simply shows no results, perhaps
displaying a generic error page.

Commonly Displayed SQL Errors

Microsoft SQL Server Errors

Consider the following request:
The error returned from the remote application will be similar to the following:
Server Error in '/' Application.
Unclosed quotation mark before the character string 'attacker;'.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: Unclosed quotation

Imagine you find a page called showproduct.aspx in the victim.com application.
The script receives a parameter called id and displays a single product depending on the value
of the id parameter:
When you change the value of the id parameter to something such as the following:
the application returns an error similar to this:
Server Error in '/' Application.
Invalid column name 'attacker'.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: Invalid column name
mark before the character string 'attacker;'.

Based on the error, you can assume that in the first instance the application creates an
SQL statement such as this:
SELECT * FROM products WHERE idproduct=2
The preceding statement returns a result set with the product whose id product field equals 2. However, when you inject a non-numeric value, such as attacker, the resultant SQL statement sent to the database server has the following syntax:
Testing for SQL Injection
SELECT * FROM products WHERE idproduct=attacker
The SQL server understands that if the value is not a number it must be a column name.
In this case, the server looks for a column called attacker within the products table. However,
there is no column named attacker, and therefore it returns an error.
There are some techniques that you can use to retrieve information embedded in the
errors returned from the database. The first one generates an error converting a string to an
http://www.victim.com/showproducts.aspx?category=bikes' and 1=0/@@version;--
Application response:
Server Error in '/' Application.
Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 – 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft
Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: ) ' to a column of data type int.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information
about the error and where it originated in the code.
The database reported an error, converting the result of @@version to an integer and displaying its contents. This technique abuses the type conversion functionality in SQL Server. We sent 0/@@version as part of our injected code. As a division operation needs to be executed between two numbers, the database tries to convert the result from the @@version function into a number. When the operation fails the database displays the content of the variable.
You can use this technique to display any variable in the database. The following |
uses this technique to display the user variable:

MySQL Errors
A common configuration is formed by an Apache Web server running PHP on a Linux operating system, but you can find it in many other scenarios as well. The following error is usually an indication of a MySQL injection vulnerability:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/victim.com/showproduct.php on line 8

In this example, the attacker injected a single quote in a GET parameter and the PHP page sent the SQL statement to the database. The following fragment of PHP code shows the vulnerability:
//Connect to the database
mysql_connect("[database]", "[user]", "[password]") or
//Error checking in case the database is not accessible
die("Could not connect: " . mysql_error());
//Select the database

When an application running the preceding code catches database errors and the SQL query fails, the returned HTML document will include the error returned by the database. If an attacker modifies a string parameter by adding a single quote the server will return
output similar to the following:
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

The preceding output provides information regarding why the SQL query failed. If the
injectable parameter is not a string and therefore is not enclosed between single quotes, the
resultant output would be similar to this:
Error: Unknown column 'attacker' in 'where clause'

Learn more on => SQL injection Contd......

Oracle Errors

When tampering with the parameters of Java applications with an Oracle back-end
database you will often find the following error:
java.sql.SQLException: ORA-00933: SQL command not properly ended at
oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180) at
The preceding error is very generic and means that you tried to execute a syntactically
incorrect SQL statement. Depending on the code running on the server you can find the
following error when injecting a single quote:
Error: SQLException java.sql.SQLException: ORA-01756: quoted string not
properly terminated
In this error the Oracle database detects that a quoted string in the SQL statement is not
properly terminated, as Oracle requires that a string be terminated with a single quote. The
following error re-creates the same scenario in .NET environments:
Exception Details: System.Data.OleDb.OleDbException: One or more errors
occurred during processing of command.
ORA-00933: SQL command not properly ended
The following example shows an error returned from a .NET application

sql injection payload => bikes’ or ‘1’=’1?  to make always true

In this example, we injected SQL code that created a meaningful correct query. If the
application is vulnerable to SQL injection, the preceding query should return every row in
the products table. This technique is very useful, as it introduces an always true condition.
‘ or ‘1’=’1 is inserted inline with the current SQL statement and does not affect the
other parts of the request. The complexity of the query doesn’t particularly matter, as we can
easily create a correct statement.

Another test to perform in this kind of situation is the injection of an always false
For that we will send a value that generates no results; for example, bikes’
AND ‘1’=’2:
FROM products
WHERE category='bikes' AND '1'='2' /* always false -> returns no rows */
54 Chapter 2 • Testing for SQL Injection
The preceding statement should return no results, as the last condition in the WHERE
clause can never be met. However, keep in mind that things are not always as simple as shown
in these examples, and don’t be surprised if you inject an always false condition and the
returns results

IMP =>
Parameter manipulation

Mitigation =>
Output encoding

Learn more on => SQL injection Contd......