SQL injection checking….

One of the most serious problems I see are SQL injections. While most SQL injections have become less of threat since SQL 2005 it doesn’t mean that they have totally gone away. While SQL injections are not the easiest attacks to pull off there are automated tools to help out and a determined hacker can present formable opponent.

Since the hacker injection leverages the connection of your web application to connect to your database server via web coding there are important places we can look at. Look at your IIS logs common SQL language. As an example the following:

  • USE
  • SELECT
  • SYS.TABLES
  • sp_password
  • xp_cmdshell

should never be passed in from our web client. If you see these in your IIS logs then you have an attempted attack. If may not signify that it was successful but attempted. To find out whether it was successful I look at following IIS log entries to see what data was being returned to your web client.

How can this happen? It really comes down to the web application passing SQL code to the database unchecked. Normally these well come from help or search type pages. If a hacker can type:

USE master SELECT * FROM sys.databases

If passed successfully then the hacker can retrieve all the databases on your SQL server.

Now that we the database names we can list all of the tables via this command:

USE SomeDatabase SELECT * FROM sys.tables

Finally, we can list the columns from all the tables in that same database:

USE AdventureWorksSELECT * FROM sys.columns

From here we can look for any interesting column name like: ccnumb, ssn, order, etc…

Remember, if they can retrieve the information they can also delete the information on your SQL server.

Tags :

About the Author

Leave a Reply

%d bloggers like this: