SQL injection attacks are one of the most common techniques hackers use to access secure information from web servers to carry out illegitimate activities. This hacking technique also demonstrates how vulnerable systems are on not just the insecure ports and other firewall protected fronts, but on HTTP port 80, as well as the user-input nature of text boxes on web pages.
By this technique, someone who is aware of what’s used in the SQL code can take advantage of loosely-written programming to view, modify and delete the restricted data even when not having the proper privileges for it. The intensity of the invasion depends mainly on the quality of the code written and the skill of the hacker trying to breach in. SQL injection mainly occurs due to the following:
- Quality of code written:
- Generally, developers writing the code do not think about special/unusual inputs which can lead to the abnormal behavior of the program, allowing a hacker to secure the privileged information
- The side effect of missing security checks in queries generated on the data provided by the end user through a web page interface:
- The hacker (or bot) starts by providing some abnormal inputs to web page text boxes, observing the consequences and moving forward on the interpretation to repeat the sequence of steps in order to crack into the privileged/desired information from the server
Process demonstration of the SQL Injection:
Open any web page written in ASP, JSP, CGI, PHP, which is intended for taking input from user, such as:
a search page, login page, reference page (http://xyz/home.asp?id_no=50), feed back page
Generally, the POST command is used for sending the input, therefore you need to check in the HTML code of the pages regarding the method used for sending the command.
FORM HTML tag is used for it, so you can just check the FORM tag in the page to judge whether SQL Injection can be applied or not, for example:
<FORM action=Search/search.asp method=post>
<input type=hidden name=XYZ value=PQR>
</FORM>
Suppose you are on a login page and need to enter a login name and password. Whatever you enter will be processed something like this:
SELECT * FROM Users WHERE user = ‘” & user_name & “‘ AND password = ‘” & user_password & “’;”
The strings user_name and user_password are the ones you have entered. The above login query, though, looks and works fine until something like this is entered:
Input user name as TED & “` -- ,
This makes the above query look like:
SELECT * FROM Users WHERE user = ‘” & TED & “` -- & “‘ AND password = ‘” & user_password & “’;”
– – will make the remaining part of the string a comment and you might be able to login if any user TED exists in the database, other common names like (MARIA, JOHN) can be tried.
Inputting TED & “` OR `1=1` — will let you login into the account of the first user in the list as the above query will always return true for all cases.
The above examples can prove to be disastrous when given.
TED & “’ ; DELETE FROM Users WHERE ‘1=1’ ; --
A ‘good’ hacker can easily take it from here. He can ‘dump’ the results to his PC, and sell the information. If the contents of your database contains credit card entries, personal information (phone number, etc.), you are in heaps of trouble. There is a very strong black market for information like this, and the hackers are paid very well for it.
Our research indicates that the majority of hackers utilize Google to find open exposures on the web. So for example, if they know that a specific version of WordPress is exposed to SQL injection techniques, they’ll search Google for the specific strings exposed in WordPress.
If your site is on Google, anywhere, and you have an SQL injection exposure, they will find you eventually. To learn more about SQL Injections and to scan your website for SQL injections download Acunetix Web Vulnerability Scanner.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
