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 12»»

SQL Injection - Part 1 Expand / Collapse
Author
Message
Posted Sunday, February 22, 2004 6:58 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, August 14, 2007 1:40 PM
Points: 42, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/RDyess/sqlinjec


Post #101632
Posted Monday, February 23, 2004 11:11 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 31, 2006 1:59 AM
Points: 6, Visits: 1
Nice article, but didn't Christoffer say all of that just 20 days ago? Check: http://www.sqlservercentral.com/columnists/chedgate/sqlinjection.asp

.
Post #101869
Posted Tuesday, February 24, 2004 1:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 2:56 PM
Points: 2,903, Visits: 1,820

SQL Injection attacks happen due to a violation of basic programming principles.

As a matter of good programming practice

  • ALWAYS validate user input.
  • ALWAYS check that data cannot exceed its bounds  i.e. the program won't try to store an SMALLINT in a BYTE field, or try and stuff a 11 byte string in a 10 byte space.
  • ALWAYS include error checking/exception handling.

I predate Microsoft so I can remember how damn grateful we were for software that was easy to use. 

The emphasis in software development was to develop a tool that could be used.  No one really looked at it from the "how could someone pervert this tool". 

The sins of the fathers are truly been visited upon their sons.  I dread to think how much code is in PC software per se that can be hacked due to unchecked bounds.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #101884
Posted Tuesday, February 24, 2004 6:33 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 4, 2014 9:46 AM
Points: 295, Visits: 280

Validating user input is really not complex at all. If you need to build and execute ad hoc queries you just need to remember two things.

With strings, always replace ticks/single-quotes (') with two ticks/single-quotes ('') <- notice there are two characters there and not a double-quote ("). If you do this then the user entry for that field will be accepted in its entirety and any SQL commands in the string, including comment markers.

Example:
User enters the following in password:
'; delete from users

You put the following code in the statement used to build SQL statement (VB 6)
sSQL = sSQL + "and password = '" & Replace (sPassword, "'", "''") & "'"

The resulting SQL statement is this:
select userid from users where userid = 'bogus' and password = '''; delete from users'

One other thing with strings. This is not so much a protection from SQL injection but will help keep errors from cropping up that could expose connection information in the form of an error response. Make sure you are limiting the size of strings in the UI to prevent people from entering text too large for the database to handle. If you are developing n-tier applications, you business layer should not trust the UI and double check the data.

For all non-string data you should use the appropriate means to determine if the input is valid for the data type that is to receive the input. If the field is an integer, check to see that the user entered an integer; same with dates, etc. Also don't assume that client-side form validation in web applications will catch this. Always check on the server-side because there is no guarantee that the user is using the form you created!



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #101926
Posted Tuesday, February 24, 2004 7:10 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 25, 2005 8:33 AM
Points: 88, Visits: 1
stored procedures, anyone?


Post #101943
Posted Tuesday, February 24, 2004 7:34 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 4, 2014 9:46 AM
Points: 295, Visits: 280

pe johnson said "stored procedures, anyone?"

In my own defense, I did say "If you need to build and execute ad hoc queries" but maybe I did not stress the need enough. There are occasions where an application needs to throw together a query based on user input.

Stored procedures are the obvious choice for security and performance and should be used whenever possible. If you look around there are some tricks for handling situations where the obvious option is to use ad hoc queries (Particularly with WHERE clauses) but you really can use stored procedures with a little thought. If you want to get fancier, look into code generation (http://www.codegeneration.net/ and my favorite http://www.ericjsmith.com/codesmith). If you find yourself using the same patterns repeatedly, write a script or other tool to reproduce the code that results from the pattern and save yourself time down the road.



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #101954
Posted Tuesday, February 24, 2004 9:03 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 25, 2005 8:33 AM
Points: 88, Visits: 1

No harm, no foul.  The comment was not really directed at anyone, I just wanted to introduce the concept of using stored procedures to short circuit injection attacks.

IMHO there is never a good reason to use dynamic sql, either as a command or wrapped in a stored procedure.  Just create as many stored procedures as you need to handle the different scenarios, and call them appropriately. 

Whenever I bring this approach up, development time up front seems to be the biggest pushback.  But using this approach not only provides the security and performance benefits you mentioned, but also abstracts the internals of the db layer from the application/business layer.  It also makes modifying application code as easy as calling a new sproc, instead of the nightmare of trying to maintain 300 lines of stored procedure code.

 




Post #101993
Posted Tuesday, February 24, 2004 9:03 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 25, 2005 8:33 AM
Points: 88, Visits: 1

No harm, no foul.  The comment was not really directed at anyone, I just wanted to introduce the concept of using stored procedures to short circuit injection attacks.

IMHO there is never a good reason to use dynamic sql, either as a command or wrapped in a stored procedure.  Just create as many stored procedures as you need to handle the different scenarios, and call them appropriately. 

Whenever I bring this approach up, development time up front seems to be the biggest pushback.  But using this approach not only provides the security and performance benefits you mentioned, but also abstracts the internals of the db layer from the application/business layer.  It also makes modifying application code as easy as calling a new sproc, instead of the nightmare of trying to maintain 300 lines of stored procedure code.

 




Post #101994
Posted Tuesday, February 24, 2004 9:39 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 4, 2014 9:46 AM
Points: 295, Visits: 280
I agree completely. In fact, the intent of of mentioning the code generation in my last post was to debunk the development time argument.

Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #102008
Posted Tuesday, February 24, 2004 11:58 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:38 AM
Points: 33,267, Visits: 15,436
good comments and a great article. One other thing that I think should be mentioned first is that the user account should not be SA, but rather a limited rights account. To me that's the first step before attempting to limit injection attacks.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #102051
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse