This is part one of the series detailing the OWASP top 10 web application vulnerabilities. (See intro)
An SQL Injection attack is a type of code injection attack where an attacker exploits a vulnerability in the database layer of an application. This can occur when user input is incorrectly filtered for escape characters. Serious system damage can be suffered such as lost data or entire databases, compromised systems etc.
A classic example of this is in login screens. A user could enter a valid username in the "username" field and a specially constructed string in the password field. If this input is not filtered correctly, the database layer could build up a SQL query which returns incorrect results. Eg, an attacker enters "Administrator" in the username field and "anything' or 1=1 --" in the password field. If the user input isn't filtered correctly, the following SQL query could be built up:
select * from user_table where user_name = 'Administrator' and password = 'anything' or 1=1 --'
Now, because (1=1) is always true, the SQL should return all users where username = 'Administrator'. Another important part is the comment characters "--". This causes the database to ignore the rest of the statement, without which the last quote at the end of the string would render the query invalid. This effectively, bypasses the password check and could allow an attacker to log into the system with any valid username. Remember that most SQL syntaxes differ slightly, so there may be many different variants of the above attack depending on the database used.
This is only a simple example, but the possibilities are endless - consider what would happen if the following statement was executed:
SELECT * FROM someTable WHERE someField = 'x'; DROP TABLE user_table; --';
This shows that it is possible to not only construct a query which returns incorrect data, but also to modify databases. It therefore doesn't take too much imagination to extend this to inserting a totally new user into the database or modifying an existing password.
Now, the question is how does an attacker learn the names of the tables or fields that some attacks rely on? Firstly, tables are normally named fairly logically, so a bit of guesswork goes a long way, but incorrect error handling is a dead give-away. A string which deliberately creates an incorrectly formatted SQL statement, will throw an exception from the database. If the entire stacktrace and message is displayed on the page, instead of an error page with a generic message, the select statement may be displayed indicating the table and field names used in the statement. This is the only opening a hacker needs...
So, Lesson 1 - As with CSS attacks, sanitise all input data.
And lesson 2 - Make sure that all exceptions are caught and make sure you handle all exceptions properly. Set up a default error page which shows a generic message.