SQL injection - Overview
'Hacking' is a term which intrigues everybody. SQL injection is a simple technique for exploiting web applications that use client-supplied data in the form of SQL queries, but without first removing potentially harmful characters. Many programmers are responsible with different roles for the development of a Web Application. This means that one programmer may not be familiar with the code/function written by another programmer for the same application. Generally this leads to vulnerabilities in the system which can be exploited.
Testing procedure:
The primary technique for testing is to insert a single quote (') into the first argument of any script. If the server returns a white blank screen with an ODBC error, Bingo! you just hit the jackpot.
Another common procedure is to use a single quote and any SQL parameter (such as " ' WHERE ") in an argument of the script. This procedure has to be repeated for every argument, while ensuring that valid data is passed into all the other arguments. This will effectively help us determine if SQL injection is posibble.
Evaluating Results:
The basic idea is 'SQL injection is succesful,if the server returns a database error'. However the error messages aren't always so obvious. The source of the entire page should be searched for terms like "ODBC", "SYNTAX" and "SQL Server", as the message details may be hidden in comments, headers, etc of the page.
Some Web Applications are designed to redirect the user/client to the main page of the site whenever an error occurs. If you encounter a 500 Error Page, then there is a good probabilty that SQL injection was successful.
Attacking:
Although there are many techniques used for SQL injection, this articles deals with 'Authorization bypass'.
Authorization Bypass:
This technique is used for bypassing logon forms. Consider the following application code
// SQLQuery = "SELECT Username FROM Users WHERE Username = ‘" &
// strUsername & "‘ AND Password = ‘" & strPassword & "‘"
// strAuthCheck = GetQueryResult(SQLQuery)
// If
// strAuthCheck = "" Then boolAuthenticated = False
// Else
// boolAuthenticated = True
// End If
When a user enters the username and password, the query will go through the Users table to check if a row with the Username and Password exist. If such a row is found, then the username is stored in the strAuthCheck variable. If no row is found then the strAuthCheck variable will be empty indicating an authenticated user.
You modify the characters of the strUsername and strPassword, such that the SQL query structure is modified, it will return a valid name from the table and authenticate you.
Consider a user filling the logon form with the following data:
Login: ' OR ''='
Password: ' OR ''='
The SQL query will then be modified as:
// SELECT Username FROM Users WHERE Username = '' OR ''='' AND
// Password = '' OR ''=''
Instead of comparing the user-supplied data with that present in the Users table, the query compares a quotatation mark to another quotation mark. Since all the conditions of the SQL query are satisfied this will result in copying the Username in the first row in the table to the strAuthCheck, successfully ensuring athentication.In the last article we discussed the definition of SQL injection, the procedure for testing if SQL injection is possible, evaluating the Error pages and an attacking technique called 'Authorization Bypass'.
Protection against SQL injection:
1. Data Sanitization:
The main factor involved in SQL inhection is the inclusion of harmful characters which act as part of the SQL query. Thus we should develop a procedure to remove such malicious characters in all applications. The best way to prevent SQL injection is to filter the data using a default-deny regular expression. This expression will only allow the characters specified, filtering out the rest. For example the following expression will only return letters and numbers:
s/[^0-9a-zA-Z]//\
Needless to say, the filter should be specific in nature so as to provide the best protection. If symbols or punctuation are required, convert them into HTML. For example, if a user is submitting an email address, only allow the 'at' (@), underscore, period and hyphen in addition with letters and numbers, and alalow them only if they have been converted into thier HTML substitutes.
2. Secure SQL coding
Make it a common practice to prefix and append a quote to all user inputs, even if the data is alpabetical or numeric. Manage authorization rights efficiently by ensuring that users are granted access to only the procedures required, rather than allowing access to all of the system-stored procedures.



A key is often needed in the embedding process. This can be in the form of a public or private key so we can encode the secret message with our private key and the recipient can decode it using public key. In embedding the information this way, we can reduce the chance of a third party attacker getting hold of the stego object and decoding it to find out the secret information.




