4 Tips for Stopping SQL Injection Attacks

While many of the security solutions on the market attempt to plug the holes found on today's systems, it still comes down to deploying the proper solutions and understanding how those solutions work to be fully effective.

Some will say that there is little wrong with taking a reputable vendor's security promises at face value, but the question remains, what exactly is that vendor protecting a network from? Take for example the all too common SQL injection attack: What is it? How do you stop it? Are your customers vulnerable? Does your security product prevent it? These are all questions that should echo through the minds of network security solution providers. While we may not have the answers, we can surely understand what the attack is and how it compromises a system.

SQL injection attacks have been the bread and butter of system crackers since the first SQL database became Web-enabled. Why is that? Simply put, if you can break through the authorization challenge presented at log-on, you can access the data stored in the SQL database. In other words, all of a customer's data can be exposed to the wrong individuals. That may not be so important when talking about a database that stores model numbers and color codes, but when the data changes to credit card or social security numbers, the game changes.

While there are several different SQL server products on the market from players such as Microsoft, Oracle, MySQL and Postgres, an attack still starts at the same entry point: a browser-based form. That is where a hacker starts to explore the vulnerabilities. For example, any Web page that executes code (ASP, JSP, CGI or PHP) can be hijacked to pass a string of SQL statements to the database server. Another place to start is to look for any Web pages that allow you to submit data, such as a login page, search page, feedback, and so-on. In some cases, those HTML based pages use a POST command to send parameters to an ASP or script processing page. A dead giveaway is to look at the source code of the HTML page and locate the "FORM" tag and the "Post" command.

NEXT: How to spot trouble and what to do about it You may find something similar to this in the HTML (Note that in the following examples, inconsistencies and errors have been introduced to prevent them from being used to launch a valid attack. Examples are for illustrative purposes only):

Anything between the two "FORM" tags could prove to be useful when building an exploit.

So, how do you test if the page is vulnerable? One trick is to try to fool the page with a single quote -- for example, you could enter into the name field hello' or 1=1-- Note the single quote at the end of the word hello. So your input would look like this:

Login: hello' 1=1-- Password: hello' 1=1--

Another method is to try to hijack the page by modifying the URL: For example, you would input into your browser the following address:

http://website.com/locate.asp?login=hello' or 1=1--

By putting an address with the input data into your browser, the browser forces the ASP page to process your input of hello' or 1 = 1--.

Now some of you may ask what is the significance of ' or 1=1--. Simply put, that is the command being injected into the ASP script, which can bypass the login script and then display additional information that would not normally be available.

In other words, if you are familiar with SQL queries, you may have access to variables contained with in the SQL Table. That information could be used to build new queries, such as:

SELECT * FROM users WHERE Names='Smith' That command would load values into a variable of our choosing from the SQL Table.

Going one step further, we could add

or 1 = 1--

to the command string and the SQL server will return all information in the table, regardless if the Names variable is equal to Smith.

So what does all this mean? If a hacker is able to get to this point and gets results, then the SQL server is definitely vulnerable. Depending upon the SQL server technology in use, a hacker could execute several different commands. Most hackers will use the EXEC command to execute a task to get output from the SQL Server, which they can redirect to a shared folder by IP address.

So with the vulnerability uncovered and access to the SQL Tables, any hacker can simply deliver all of the data in a SQL Database to a destination of their choosing.

Armed with an understanding of how SQL injection attacks work, administrators can take steps to prevent those attacks. In many cases administrators will have to work with their software and Web developers to implement some basics rules that offer additional protection.

1. Employ filters that prevent characters like single or double quotes, backslashes, colons and so on from being passed from a web form into the SQL Server.

2. Only allow numeric values that are integers to be passed to the SQL Server, that can be handled by simply using the ISNUMERIC command to validate the input.

3. Delete stored procedures from the SQL database that are not needed. Examples are xp_sendmail or xp_cmdshell, which are not normally needed, but can be used by hackers to send information or gain access.

4. Check privileges behind SQL commands, such as Startup and RUN, on the SQL Server Security TAB (for Microsoft SQL Server) and make sure the appropriate privileges are assigned for your environment.