SQL injection attacks are also often referred to as SQL malware.  Like local and remote file inclusion attacks, an SQL injection attack inserts a malicious script into a website’s code.  In this case, a web page that is using a tool like MySQL to query and manipulate a database through SQL (Structured Query Language) is vulnerable.

An SQL injection attack uses an HTTP string with embedded SQL commands to gain access to otherwise secure information in a database, or to maliciously insert data into a database.  A brief overview of how this attack works is included here for example purposes.  An SQL injection attack might look something like this in the access log for a website:

GET /Display.php?ArticleID=OR 1=1;

This line contains SQL query code.  The origin of this script might be a web page that displays a search box to allow visitors to enter search text.  The web page script uses the text in the HTTP string from the search box to look up database entries and then display them on an output web page.

Consider a PHP script in the Display.php output page that makes use of SQL for database searches.  An SQL command in the script contains a variable that represents a search term, and this variable is supplied by the search text input by the website visitor.  Once the visitor has entered the search text and clicks a button to initiate the search, the Display.php script derives the search terms from the visitor’s search text.  The search text is inserted into the SQL search command and a database search takes place.  The results of the search are then displayed.

In the example line above, the text “OR 1=1” is the search text entered by the visitor.  Since the visitor’s search text is inserted into an SQL command, the Display.php script must carefully validate the content of the text.  When the search text is valid, the query can be executed without a problem.  However, if the user entered a partial SQL command, then it could inadvertently be executed by the script.  Depending on the SQL command that is entered by the visitor, the result may vary from unexpected to disastrous.

Looking at the simple example above, imagine that the Display.php script is intended to retrieve one entry from the database and display it.  A malicious visitor in this case has input a partial SQL command that always tests as true (“OR 1=1”).  This partial command, when inserted into the SQL command in the page’s script, will cause the script to find a match in every entry.  The result is that every entry in the database will be retrieved and displayed.  At this point, the security of the database has been severely compromised.

To avoid an SQL injection attack, a web page’s script must do some checking on search text and make sure that it only contains valid data.  This could mean checking to allow numbers and letters but not symbols such as ‘=’.  When symbols are present in the search text, the text should be discarded and no operation performed.  The visitor could be notified of the invalid input with a message and asked to input valid text only.  Other more complicated strategies can also be employed to ensure the validity of search text that is input by web site visitors.

Another example of an SQL injection attack uses partial SQL commands to modify database entries.  Each record in the database will have malicious iframe or JavaScript code inserted.  When a legitimate script accesses the database, the malicious code is activated.  A trojan virus called Asprox uses this method to embed itself in mainstream government and retail websites and is spread to visitors who access data on the infected websites.  Since 2008, Asprox has been used to fraudulently access the bank accounts and financial data of thousands of computer users.

Ideally one should use a web vulnerability scanner such as Acunetix WVS to check if his website is vulnerable to SQL injections.

SHARE THIS POST
THE AUTHOR
Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

Comments are closed.