4 Tips for Stopping SQL Injection Attacks

One of the best ways to provide security is to understand the weaknesses prevalent in today's Web-connected systems. Regrettably, ignorance has become the rule when it comes to securing these systems, whether it's ignorance on the part of the security professional who just deploys vendor-recommended patches and solutions or ignorance on the part of the end user, who simply doesn't understand how security threats impact operations.

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