SQL Server

SQL Injection Attack Talk in Nuneaton

Colin Angus Mackay — Wed, 02 Dec 2009 10:18:47 GMT

I’ll be speaking to VBUG in Nuneaton on the 12th January 2010 on the subject of SQL Injection Attacks and Tips on How to Prevent Them.

More details on this event can be found on the VBUG website.

Visual Studio / SQL Server install order on Windows 7

Colin Angus Mackay — Sun, 11 Oct 2009 10:50:22 GMT

Quite a while ago I blogged about the Visual Studio / SQL Server install order on Windows Vista. I’m about to go through a similar exercise on Windows 7 and given the issues I had then I thought that it would be only right to document the procedure in case any problems arose.

Last time, it would seem, the best solution was to install things in the order in which Microsoft released them with the notable exception of the operating system. So this time, that is the strategy that I’m going to take. Windows 7 is already installed on my laptop. Then I’m going to install Visual Studio 2008, then SQL Server 2008, then any patches for either and we’ll see how we get on.

I’m also going to ensure that I do NOT install SQL Server Express Edition on Visual Studio 2008 as I’ve had problems with that before. Essentially, the problem last time was that the SQL Server installer mistook Visual Studio’s SQL Server Express installation has having installed certain things. The SQL Server installation therefore didn’t want to repeat what it didn’t need to so it refused to install the client tools.

Install Order

Visual Studio 2008, excluding SQL Server 2005 Express Edition

MSDN Library (This is optional – I installed it because I’m occasionally developing on the road with no or limited connectivity)
Visual Studio 2008 Service Pack 1 (this is required in order to install SQL Server 2008 – the installation will fail otherwise)
SQL Server 2008 Developer Edition

Install SQL Server 2008 SP1

That’s it – Job done. And it only took me two attempts to get it right this time. My stumbling block here was the order in which I applied the service packs.

Technorati Tags: sql server,sql server 2008,visual studio,visual studio 2008,installation

SQL Injection Attacks and Tips on How to Prevent Them

Colin Angus Mackay — Thu, 24 Sep 2009 03:29:25 GMT

I’m giving a talk in Dundee on the topic of SQL Injection Attacks. If you are interested in the subject then the registration link is at the bottom of the page.

Wednesday, 28th October 2009 at 19:00 – 21:00
Queen Margaret Building, Dundee University

The Talk

In light of some recent events, such as the man who was convicted of stealing 130 million credit card details through a SQL Injection attack, it is imperative that developers understand what a SQL Injection Attack is, how they are carried out, and most importantly, how to defend your code against attack.

In this talk I’ll demonstrate a SQL Injection Attack on an application in a controlled environment*. I’ll show you where the vulnerable code lies and what you can do to harden it.

Although this talk uses C# as the application language and Microsoft SQL Server 2008 as the database engine many of the concepts and prevention mechanisms will apply to any application that accesses a database through SQL.

* Demonstrating an attack on a real system without the owner’s consent is a breach of the 1990 Misuse of Computers Act, hence the controlled environment.

The Venue

We are meeting in the Queen Mother Building at Dundee University. After the meeting we normally retire to the the bar at Laing's

The Agenda

18:45 Doors Open
19:00 Welcome
19:10 The Talk (Part 1)
19:55 Break
20:05 The Talk (Part 2)
20:45 Feedback & Prizes
21:00 Repair to the Pub

Registration

Space is limited, we would therefore ask that you sign up.

Technorati Tags: sql,sql injection attack,security

If you really must do dynamic SQL…

Colin Angus Mackay — Mon, 21 Sep 2009 18:15:01 GMT

I may have mentioned in previous posts and articles about SQL Injection Attacks that dynamic SQL (building SQL commands by concatenating strings together) is a source of failure in the security of a data driven application. It becomes easy to inject malicious text in there to cause the system to return incorrect responses. Generally the solution is to use parameterised queries

However, there are times where you may have no choice. For example, if you want to dynamically reference tables or columns. You can’t do that as the table name or column name cannot be replaced with a parameter. You then have to use dynamic SQL and inject these into a SQL command.

The problem

It is possible for SQL Server to do that concatenation for you. For example:

CREATE PROCEDURE GetData 
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
	SET NOCOUNT ON;
	
	DECLARE @sql nvarchar(max) = 
		'SELECT ' + @ColumnName + 
		' FROM ' + @TableName + 
		' WHERE Id = '+cast(@Id as nvarchar(20));	
	EXEC(@sql)
END
GO

This is a simple stored procedure that gets some data dynamically. However, even although everything is neatly parameterised it is no protection. All that has happened is that the location for vulnerability (i.e. the location of the construction of the SQL) has moved from the application into the database. The application is now parameterising everything, which is good. But there is more to consider than just that.

Validating the input

The next line of defence should be verifying that the table and column names passed are actually valid. In SQL Server you can query the INFORMATION_SCHEMA views to determine whether the column and tables exist.

If, for example, there is a table called MainTable in the database you can check it with a query like this:

SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'MainTable'

And it will return:

There is a similar view for checking columns. For example:

As you can see, the INFORMATION_SCHEMA.COLUMNS view also contains sufficient detail on the table so that when we implement it we only have to make one check:

ALTER PROCEDURE GetData 
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;
	
    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS 
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) = 
            'SELECT ' + @ColumnName + 
            ' FROM ' + @TableName + 
            ' WHERE Id = '+cast(@Id as nvarchar(20));	
        EXEC(@sql)
    END
END
GO

Formatting the input

The above is only part of the solution, it is perfectly possible for a table name to contain characters that mean it needs to be escaped. (e.g. a space character or the table may share a name with a SQL keyword). To escape a table or column name it is enclosed in square brackets, so a table name of My Table becomes [My Table] or a table called select becomes [select].

You can escape table and column names that wouldn’t ordinarily require escaping also. It makes no difference to them.

The code now becomes:

ALTER PROCEDURE GetData 
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;
	
    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS 
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) = 
            'SELECT [' + @ColumnName + '] ' + 
            'FROM [' + @TableName + '] ' +
            'WHERE Id = '+cast(@Id as nvarchar(20));	
        EXEC(@sql)
    END
END
GO

But that's not quite the full story.

Really formatting the input

What if you have a table called Cra]zee Table? Okay - Why on earth would you have a table with such a stupid name? It happens, and it is a perfectly legitimate table name in SQL Server. People do weird stuff and you have to deal with it.

At the moment the current stored procedure will simply fall apart when presented with such input. The call to the stored procedure would look like this:

EXEC GetData 1, 'Cra]zee Table', 'MadStuff'

And it gets past the validation stage because it is a table in the system. The result is a message:

Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'Table'.

The SQL produced looks like this:

SELECT [MadStuff] FROM [Cra]zee Table] WHERE Id = 1

By this point is should be obvious why it failed. The SQL Parser interpreted the first closing square bracket as the terminator for the escaped section.

There are other special characters in SQL that require special consideration and you could write code to process them before adding it to the SQL string. In fact, I’ve seen many people do that. And more often than not they get it wrong.

The better way to deal with that sort of thing is to use a built in function in SQL Server called QUOTENAME. This will ensure the column or table name is properly escaped. The stored procedure we are now building now looks like this:

ALTER PROCEDURE GetData 
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;
	
    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS 
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) = 
            'SELECT ' + QUOTENAME(@ColumnName) +
            ' FROM ' + QUOTENAME(@TableName) + 
            ' WHERE Id = '+cast(@Id as nvarchar(20));	
        EXEC(@sql)
    END
END
GO

Things that can be parameterised

There is still something that can be done to this. The Id value is being injected in to the SQL string, yet it is something that can quite easily be parameterised.

The issue at the moment is that the SQL String is being executed by using the EXECUTE command. However, you cannot pass parameters into this sort of executed SQL. You need to use a stored procedure called sp_executesql. This allows parameters to be defined and passed into the dynamically created SQL.

The stored procedure now looks like this:

ALTER PROCEDURE GetData 
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;
	
    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS 
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) = 
            'SELECT ' + QUOTENAME(@ColumnName) +
            ' FROM ' + QUOTENAME(@TableName) + 
            ' WHERE Id = @Identifier';	
        EXEC sp_executesql @sql, N'@Identifier int',
                           @Identifier = @Id
    END
END
GO

This is not quite the end of the story. There are performance improvements that can be made when using sp_executesql. You can find out about these in the SQL Server books-online.

And finally...

If you must use dynamic SQL in stored procedures do take care to ensure that all the data is validated and cannot harm your database. This is an area in which I tread very carefully if I have no other choice.

Try and consider every conceivable input, especially inputs outside of the bounds of your application. Remember also, that defending your database is a multi-layered strategy. Even if you have the best firewalls and security procedures elsewhere in your system a determined hacker may find a way though your other defences and be communicating with the database in a way in which you didn’t anticipate. Assume that an attacker has got through your other defences, how do you provide the data services to your application(s) yet protect the database?

Technorati Tags: sql,sql server,sql injection attack,dynamic sql

SQL Injection Attack Prevention talk

Colin Angus Mackay — Sun, 23 Aug 2009 12:41:58 GMT

In light of some recent events, such as the man who was convicted of stealing 130 million credit card details through a SQL Injection attack and hotel websites that vomit up SQL, I’ve decided to revive my SQL Injection Attacks (and how to prevent them) talk.

I’ve already submitted it for consideration for SQL Bits V. But I’m also happy to come along to user groups that want to hear it.

SQL Server Spatial Queries talk

Colin Angus Mackay — Thu, 13 Nov 2008 00:14:52 GMT

Well, I was battling a huge cold that day but SQL Bits have still put up the talk I did on SQL Server 2008 Spatial Queries. They've edited it to take out the point I coughed so loudly I almost blew out the speakers which is good.

Developing with SQL Server 2008, deploying on SQL Server 2005

Colin Angus Mackay — Sun, 31 Aug 2008 23:18:04 GMT

I received the following by email today:

Hi Colin! I found your blog after googling for a bit about SQL Server. I had a question for you... As someone fairly new to .NET development, would it be easier to stick with SQL Server 2005 for now, or just install SQL Server 2008 express? I ask because I don't yet know enough about the differences between the two to know if there will be any issues when developing small web applications with 2008, but then deploying them to a hosting provider with 2005. Hope that makes sense. :)

Cheers,
Sean

I don't recommend moving to SQL Server 2008 if you will ultimately be deploying on SQL Server 2005.

If you don't know the difference between SQL Server 2005 and 2008, yet your hosting provider only supports 2005 then you would be better off sticking to working with SQL Server 2005 on your system. The reason for this is that you don't want to accidentally stumble into features of 2008 that are not supported on 2005.

Also, even if you were intimately aware of the differences between the two versions it is still a good rule of thumb to develop on a system that is as close to the eventual live system as you can. That way you won't get any unexpected nasty surprises when you do deploy the application and suddenly realise that things are not quite as expected.

If you have already developed the applications then you can set the compatibility level of the database to mimic SQL Server 2005:

ALTER DATABASE [MyDatabaseName] SET COMPATIBILITY_LEVEL = 90

That way you should have a similar (although not necessarily quite the same) experience as if you were developing on a real SQL Server 2005 system. There will still be things that you cannot do. I don't think backing up your 2008 database and restoring it on a 2005 system will work.

Advert for SQL Bits III

Colin Angus Mackay — Sat, 09 Aug 2008 11:24:50 GMT

SQL Bits III will be held on 13th September 2008.

Technorati Tags: SQL Bits,SQL Bits III

SQL Server 2008 RTM

Colin Angus Mackay — Thu, 07 Aug 2008 00:24:59 GMT

It would appear that SQL Server 2008 has finally RTM'ed. MSDN and TechNet subscribers can now download it from their respective websites.

SQL Server / Visual Studio Install Order

Colin Angus Mackay — Sun, 03 Aug 2008 14:02:10 GMT

Yesterday I paved my laptop in order to upgrade to Windows Vista. I've now started to reinstall everything from scratch again. However, one thing that didn't work out was the installation of SQL Server 2005. No matter what I tried I could not seem to get it to install the SQL Server Management Studio - somehow it was convinced that it already existed. I eventually figured out why.

I'd installed Visual Studio 2008 first, and as part of that installation it installed SQL Server 2005 Express edition. The express edition does not come with SQL Server Management Studio. When I went to install SQL Server 2005 it refused to install the management studio saying that more up-to-date versions of the tools were already available on the machine. (Well, I suppose some of them were, at least the ones installed by Visual Studio 2008's installer). Running the Service Pack 2 upgrade did not help either. It concluded that the client tools were not valid as part of the upgrade and refused to install them.

Eventually I came to the conclusion that it would be quicker, given my recent wiping of my laptop to just start afresh again and install things in the correct order. I suppose I was lucky to have that option. I am also lucky that I don't activate Windows until I'm sure everything is installed correctly - after all I do have 30 days to activate Windows. I'd hate to have lost an activation of Windows because of a dodgy install.

So what is the installation order I've now used that works:

Windows Vista SP1
Windows Update (my install required 33 updates)
SQL Server 2005
SQL Server 2005 SP2
Visual Studio 2008

Technorati Tags: sql server,sql server 2005,visual studio,visual studio 2008,windows,vista,windows vista,sql server 2005 express,sql server express,installation,install

PLEASE NOTE: The above is what worked for me. I've also heard that it has worked for others too. It comes with no warranties of any kind.

If you are having difficulty installing your SQL Server you may like to ask a question on one of the many fine forums that are available for asking questions of that nature. I tend to hang out on Code Project and may be able to help there. If I'm not around then one of the many other great members can possibly help you on their database forum.