Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456

A Hex on Your Database Expand / Collapse
Author
Message
Posted Wednesday, June 18, 2008 11:20 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, September 24, 2014 1:20 PM
Points: 1,276, Visits: 1,135
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]


This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though :)


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.
Post #519291
Posted Wednesday, June 18, 2008 2:30 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, April 19, 2010 6:47 AM
Points: 100, Visits: 130
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]



Dobberteen, there are two solutions. First (best) is using a parameter.
rs.Source = "SELECT * FROM Orders WHERE OrderID = @OrderID"

The problem is that using parameter in old .asp ado vb code is a bit of a pain.

Second (quickest) solutions are: if your OrderID is an int, just use something like
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & CInt(Request.QueryString("OrderID")) & "'"

If your IDs are strings, use something like
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Left(Request.QueryString("OrderID"), myFieldLength) & "'"

Post #519432
Posted Monday, July 14, 2008 4:19 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, January 22, 2009 9:09 AM
Points: 211, Visits: 18
@Christian Buettner

Standard injection attacks often work on the basis of form entry and then accurately guessing that there will be injectable code at the other end. Often works on username/password entry where the page that interprets the entry only checks to see if count of the matching username/password is one or more -

select count(*) from login where username = @username and password = @password

Then its a simple matter of using apostrophes and semi-colons to do a destructive query.

This is a newer injection that I have seen first hand and it relies not on form entry but on parameterized pages eg:

http://www.injectme.com/search.asp?search=hitmebabyonemoretime

It merely guesses that search.asp has some direct Sql similar to the form based injection. Interesting that the new injection uses hex, but fundamentally it is easier to retrospectively discover because it is as clear as day in the weblogs.



Post #533379
Posted Monday, July 14, 2008 4:26 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, January 22, 2009 9:09 AM
Points: 211, Visits: 18
@Tao Klerks

I guessed the right answer without reading the question at any length because I'd seen it before!

As I am more of a developer who uses Sql than a Dba with an understanding of coding I am also aware of the continuing debate amongst developers who want to use inline Sql as opposed to SPs. But I believe that you are right in saying use SPs, and parameters and you *should* be alright.




Post #533383
Posted Tuesday, July 15, 2008 6:41 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, March 3, 2010 12:51 AM
Points: 121, Visits: 109
the string 0x73656C656374206E616D652066726F6D207379732E6461746162617365733B actually has some meaning? I quite don't get why a string like this is used in the question.
Or is it just any string that generates an error on the server and thus displays a listing of the databases?

edit: never mind, found it in one of the posts :) "select name from sys.databases;"

however, i tried it and got only some errors :)
Post #534308
Posted Tuesday, July 15, 2008 7:29 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:49 PM
Points: 6,098, Visits: 8,364
yavvie (7/15/2008)
the string 0x73656C656374206E616D652066726F6D207379732E6461746162617365733B actually has some meaning? I quite don't get why a string like this is used in the question.
Or is it just any string that generates an error on the server and thus displays a listing of the databases?


Hi Yavvie,

Run the code below in a query window and you'll see the meaning of this string.

SELECT CAST(0x73656C656374206E616D652066726F6D207379732E6461746162617365733B AS varchar(50))




Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #534365
Posted Tuesday, July 15, 2008 1:58 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 4:52 AM
Points: 51, Visits: 124
Mike C (6/18/2008)
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]


This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though :)


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.


I couldn't agree more about the shaky nature of the 'fix' that we've put in place to stop this *one* type of exploit... Again, we've been lucky as this is the only type of attack that we're seeing. I'd hate to see what would happen if someone decided to start guessing object names and then DROPping them - actually, I wouldn't need to see it, I know exactly what would happen.

I'm sure it's obvious that I'm not a DBA - my role leans much more to the development side... but since I am the only guy at my office w/a modicum of SQL server experience, I am called on to fulfill a quasi-DBA role from time to time. Ah the joys of working in a tiny shop! :)
Post #534729
Posted Wednesday, July 16, 2008 1:47 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, April 19, 2010 6:47 AM
Points: 100, Visits: 130
dobberteen (7/15/2008)
Mike C (6/18/2008)
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]


This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though :)


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.


I couldn't agree more about the shaky nature of the 'fix' that we've put in place to stop this *one* type of exploit... Again, we've been lucky as this is the only type of attack that we're seeing. I'd hate to see what would happen if someone decided to start guessing object names and then DROPping them - actually, I wouldn't need to see it, I know exactly what would happen.

I'm sure it's obvious that I'm not a DBA - my role leans much more to the development side... but since I am the only guy at my office w/a modicum of SQL server experience, I am called on to fulfill a quasi-DBA role from time to time. Ah the joys of working in a tiny shop! :)


Dobberteen,

Doing something like:
rs.Source = "SELECT * FROM Orders WHERE OrderID = " & CInt(Request.QueryString("OrderID"))

should be easy and quick enough (provided, of course, that your order IDs were integers).

Since it looks like you are using string IDs, let's say they are 10 chars long:
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Left(Request.QueryString("OrderID"), 10) & "'"

Those fixes will probably let you sleep a bit better at night. ;)
Post #534958
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse