SQL Injection: What is it?

SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. It is perhaps one of the most common application layer attack techniques used today. It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database. In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly. SQL Injection: An In-depth Explanation Web applications allow legitimate website visitors to submit and retrieve data to/from a database over the Internet using their preferred web browser. Databases are central to modern websites they store data needed for websites to deliver specific content to visitors and render information to customers, suppliers, employees and a host of stakeholders. User credentials, financial and payment information, company statistics may all be resident within a database and accessed by legitimate users through off-the-shelf and custom web applications. Web applications and databases allow you to regularly run your business. SQL Injection is the hacking technique which attempts to pass SQL commands (statements) through a web application for execution by the backend database. If not sanitized properly, web applications may result in SQL Injection attacks that allow hackers to view information from the database and/or even wipe it out. Such features as login pages, support and product request forms, feedback forms, search pages, shopping carts and the general delivery of dynamic content, shape modern websites and provide businesses with the means necessary to communicate with prospects and customers. These website features are all examples of web applications which may be either purchased off-the-shelf or developed as bespoke programs. These website features are all susceptible to SQL Injection attacks which arise because the fields available for user input allow SQL statements to pass through and query the database directly. SQL Injection: A Simple Example Take a simple login page where a legitimate user would enter his username and password combination to enter a secure area to view his personal details or upload his comments in a forum. When the legitimate user submits his details, an SQL query is generated from these details and submitted to the database for verification. If valid, the user is allowed access. In other words, the web application that controls the login page will communicate with the database through a series of planned commands so as to verify the username and password combination. On verification, the legitimate user is granted appropriate access. Through SQL Injection, the hacker may input specifically crafted SQL commands with the intent of bypassing the login form barrier and seeing what lies behind it. This is only possible if the inputs are not properly sanitised (i.e., made invulnerable) and sent directly with the SQL query to the database. SQL Injection vulnerabilities provide the means for a hacker to communicate directly to the database. The technologies vulnerable to this attack are dynamic script languages including ASP, ASP.NET, PHP, JSP, and CGI. All an attacker needs to perform an SQL Injection hacking attack is a web browser, knowledge of SQL queries and creative guess work to important table and field names. The sheer simplicity of SQL Injection has fuelled its popularity. Why is it possible to pass SQL queries directly to a database that is hidden behind a firewall and any other security mechanism? Firewalls and similar intrusion detection mechanisms provide little or no defense against full-scale SQL Injection web attacks. Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your web application/s (generally over port 80/443). The web application has open access to the database in order to return (update) the requested (changed) information. In SQL Injection, the hacker uses SQL queries and creativity to get to the database of sensitive corporate data through the web application. SQL or Structured Query Language is the computer language that allows you to store, manipulate, and retrieve data stored in a relational database (or a collection of tables which organise and structure data).

SQL is, in fact, the only way that a web application (and users) can interact with the database. Examples of relational databases include Oracle, Microsoft Access, MS SQL Server, MySQL, and Filemaker Pro, all of which use SQL as their basic building blocks. SQL commands include SELECT, INSERT, DELETE and DROP TABLE. DROP TABLE is as ominous as it sounds and in fact will eliminate the table with a particular name. In the legitimate scenario of the login page example above, the SQL commands planned for the web application may look like the following: SELECT count(*) FROM users_list_table WHERE username=FIELD_USERNAME AND password=FIELD_PASSWORD In plain English, this SQL command (from the web application) instructs the database to match the username and password input by the legitimate user to the combination it has already stored. Each type of web application is hard coded with specific SQL queries that it will execute when performing its legitimate functions and communicating with the database. If any input field of the web application is not properly sanitised, a hacker may inject additional SQL commands that broaden the range of SQL commands the web application will execute, thus going beyond the original intended design and function. A hacker will thus have a clear channel of communication (or, in layman terms, a tunnel) to the database irrespective of all the intrusion detection systems and network security equipment installed before the physical database server. Is my database at risk to SQL Injection? SQL Injection is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against SQL Injection, there are a large number of web applications that remain vulnerable. According to the Web Application Security Consortium (WASC) 9% of the total hacking incidents reported in the media until 27th July 2006 were due to SQL Injection. More recent data from our own research shows that about 50% of the websites we have scanned this year are susceptible to SQL Injection vulnerabilities. It may be difficult to answer the question whether your web site and web applications are vulnerable to SQL Injection especially if you are not a programmer or you are not the person who has coded your web applications. Our experience leads us to believe that there is a significant chance that your data is already at risk from SQL Injection. Whether an attacker is able to see the data stored on the database or not, really depends on how your website is coded to display the results of the queries sent. What is certain is that the attacker will be able to execute arbitrary SQL Commands on the vulnerable system, either to compromise it or else to obtain information. If improperly coded, then you run the risk of having your customer and company data compromised. What an attacker gains access to also depends on the level of security set by the database. The database could be set to restrict to certain commands only. A read access normally is enabled for use by web application back ends. Even if an attacker is not able to modify the system, he would still be able to read valuable information. What is the impact of SQL Injection? Once an attacker realizes that a system is vulnerable to SQL Injection, he is able to inject SQL Query / Commands through an input form field. This is equivalent to handing the attacker your database and allowing him to execute any SQL command including DROP TABLE to the database! An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information. Depending on the back-end database in use,

SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to manipulate existing queries, to UNION (used to select related information from two tables) arbitrary data, use subselects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database server functions). If an attacker can obtain access to these procedures, it could spell disaster. Unfortunately the impact of SQL Injection is only uncovered when the theft is discovered. Data is being unwittingly stolen through various hack attacks all the time. The more expert of hackers rarely get caught. Example of a SQLInjection Attack Here is a sample basic HTML form with two inputs, login and password. <form method="post" action="http://testasp.vulnweb.com/login.asp"> <input name="tfUName" type="text" id="tfUName"> <input name="tfUPass" type="password" id="tfUPass"> </form>

The easiest way for the login.asp to work is by building a database query that looks like this: SELECT id FROM logins WHERE username = '$username' AND password = '$password If the variables $username and $password are requested directly from the user's input, this can easily be compromised. Suppose that we gave "Joe" as a username and that the following string was provided as a password: anything' OR 'x'='x SELECT id FROM logins WHERE username = 'Joe' AND password = 'anything' OR 'x'='x' As the inputs of the web application are not properly sanitised, the use of the single quotes has turned the WHERE SQL command into a two-component clause. The 'x'='x' part guarantees to be true regardless of what the first part contains. This will allow the attacker to bypass the login form without actually knowing a valid username / password combination! How do I prevent SQL Injection attacks? Firewalls and similar intrusion detection mechanisms provide little defense against full-scale web attacks. Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your databases servers through web applications. Isnt this what they have been designed to do? Patching your servers, databases, programming languages and operating systems is critical but will in no way the best way to prevent SQL Injection Attacks.

Heuristic SQL Injection Detection for Suhosin

Today I added a little simple SQL Injection Detection Heuristic to the development version of the Suhosin extension that can optionally log and block SQL queries. At the moment it is possible to log and/or block mysql(i) SQL queries that contain comments, comments that are not closed, queries with UNIONs or queries with multiple SELECT statements.

While this are very trivial checks they are very powerful and effective against a large number of SQL Injection attacks. Many PHP applications never have comments in their SQL statements, therefore any embedded comment and especially unclosed /* comments could be attempts to truncate the data after the injection point. The same is true for UNION and multiple SELECT statements (in subqueries). Both features are not used in the majority of open source PHP applications because they are not needed for the tasks or because compatibility with old MySQL versions was kept for a long time. Therefore an SQL Injection attack is very likely when either one is encountered.

Future versions of Suhosin will have a learning mode that learns the structure of allowed SQL queries and will log/block all violating queries. The release of the nextSuhosin version that contains the simple heuristic and some bugfixes is planned for 1st January. Posted by Stefan Esser in Security, PHP at 23:55 Comments (13) Link to this post

Comments
Display comments as (Linear | Threaded)

#1 Ilia Alshanetsky wrote (Link) ()

UNIONS are starting to be quite common especially in MySQL code I've recently been reviewing. I hope that the option to block queries with them is a separate config directive. posted on Thursday, December 28. 2006 #1.1 Stefan Esser wrote (Link) () Of course this are all separate config options. However the majority of open source products do not use UNION. posted on Thursday, December 28. 2006 #1.1.1 Tobias Struckmeier () Hi Stefan, it would be interesting if those features are enabled by default or not. Can you give me information on that? Cheers, Tobias posted on Thursday, December 28. 2006 #1.1.1.1 Stefan Esser wrote (Link) () Suhosin (unless you are using a beta/developer version) does not activate features by default that could break secure applications. And because it is possible that secure applications use UNION or subSELECTS, or comments it is not activated. And even if it is activated it is possible to disable the feature from .htaccess (and maybe even from ini_set in the release on 1st January). posted on Thursday, December 28. 2006 #1.1.2 Maarten Manders wrote (Link) () UNION can be quite useful: http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-onunion-for-query-optimization-query-profiling/ posted on Friday, December 29. 2006 #1.1.2.1 Stefan Esser wrote (Link) () I am fully aware that UNION can have a huge impact on the performance of applications. I used it myself to eliminate performance problems in 3rd party sites. However if you look into Open Source PHP application you will have to look at many many many many to find just one application that uses UNION. All the usual suspects like phpBB, Wordpress, S9y,... do

not need them. Therefore it is a good idea to let the admin decide if he allows these things or not. Infact he can let it run with log only mode for a while to be sure and later he can activate the blocking, so that such queries are blocked. And if he does not want to block he can leave it activated for logging only and just send himself an email whenever such a query is executed. And infact the logging script could also postprocess the query and ignore legal ones... posted on Friday, December 29. 2006 #2 nick wrote (Link) () Lemme start by saying I only recently started lurking in discussions of security concerns like SQL injection but never really commented on it. Also I've spent very little time coding against MySQL db's despite having spent the last 6 years writing PHP code. (all Oracle.) It seems to me that removing the source of SQL injections would be the most effective way to deal with them. For me that means using only bind queries. So, I would imagine creating a security patch that hamstrings oci_parse() to fail when called with a query string containing quoted values. That'd force the developer to write queries using bind variables, use oci_bind_by_name(), and eliminating SQL injections as a possibility. I don't know what the correlary would be in MySQL because as I understand it, MySQL doesn't have bind variables. Maybe a patch could force the user to emulate the behavior that PDO allows regarding prepared query strings with ? as placeholder for values. Anyway. I'm sure I don't have all the angles. But if you want to prevent SQL injections, why even allow developers to write injectable SQL? posted on Thursday, December 28. 2006 #2.1 Stefan Esser wrote (Link) () First of all mysql has bind variables if you use the mysqli extension. Secondly Suhosin is not about forcing application developers to use other functions, but to help administrators of PHP servers to protect their servers against common problems in PHP and PHP applications. Therefore it is not Suhosin's job to stop the usage of function xyz. And last but not least prepared statements are not a protection against SQL Injection. Prepared statements are meant for faster reuse of SQL queries that all follow the same syntax. It is true that when only bind parameters are used SQL Injection is impossible (if there is not a bug in the SQL engine), but SQL Injection is still possible when for example table names or order by statements are dynamically inserted. Additionally web applications often need dynamically different SQL Queries like ... field_xyz in (1,2,3,4) ... Whenever such a construct is used, it is often firectly inserted into the statement before it is passed to the "preparation" process. And don't tell me that these are unimportant cases. The cases mentioned are exactly the places that contain SQL Injection problems in otherwise safe applications, because there are no escaping functions

for table names, order by statements or value lists. And afaik there are also no bind parameters for these cases. (At least not in MySQL) posted on Thursday, December 28. 2006 #2.1.1 nick wrote (Link) () The use case of variable field or table names is certainly valid - off the top of my head I'm pretty sure you can't bind values to those parts of the query in Oracle or Postgres. But then again, I'm sure I've never tried it. posted on Thursday, December 28. 2006 #3 JW () Interesting. Wondering if its possible to fingerprint SQL. Possibly by removing any constants and/or whitespace, and hashing, then could use that as a whitelist. Also perhaps functions like mysqli_multi_query(), which allow multiple sql statements to be executed, and therefore more flexible when it comes to SQL injection may need to be limited. posted on Friday, December 29. 2006 #4 Marten Veldthuis wrote (Link) () Upon reading this I had an idea for another kind of SQL Injection prevention from the Suhosin side, not sure if it's possible though. Would it be possible to combine knowledge about the querystring and about queries being executed to (My)SQL. Meaning, you might be able to detect whether SQL keywords are appearing in the querystring, which are also subsequently being passed into the SQL query. Again, not sure about the feasibility, but I'd love to hear. posted on Friday, December 29. 2006 #5 Dave () MySQL comments are used to differentiate between different versions of MySQL... posted on Sunday, December 31. 2006 #5.1 Stefan Esser wrote (Link) () And your point is? You know SQL Queries are for retrieving and manipulating Data... But this statement is also irrelevant. The majority of Open Source Applications does not have comments in their SQL Queries and therefore the admin can configure Suhosin for these applications to disallow comments. posted on Sunday, December 31. 2006