You're piggy-backing on legitimate access. In other words, a database call that is authorized is being made. You jump in on this call and add to it.

Think of it in these terms: I have a building that requires badge access. I wait for someone to badge in, catch the door before it closes, and I'm in. The reason the door opened was because someone with legitimate access badged in. Because said person didn't make sure the door closed properly with no one else slipping through, I'm in.

With SQL Injection, the input coming in to a web page (such as GetInfo.asp, for instance), isn't properly checked. Imagine where GetInfo.asp gets a field, ID. So the link looks something like:

http://www.myserver.com/GetInfo.asp?id=7

And the code just takes the 7 and does something similar to:

SELECT * FROM Users WHERE ID = ?

And the ? is of course replaced by whatever is coming in. If I append the following (I'll use regular characters instead of URL encoded):

http://www.myserver.com/GetInfo.asp?id=7;EXEC sp_addlogin 'MyLogin', 'MyPassword'

SQL Server will actually get the following passed to it:

SELECT * FROM Users WHERE ID = 7

as well as

EXEC sp_addlogin 'MyLogin', 'MyPassword'

The attacker is using a legitimate connection and hitching a ride.

K. Brian Kelley

http://www.truthsolutions.com/

Author: Start to Finish Guide to SQL Server Performance Monitoring

http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1