8/8/2019 Identifying SQL Injection Vulnerabilities

1/2

Identifying SQL Injection Vulnerabilities

y Check your sites that have query string values (e.g., search for URLs with"form=", id=, and so on in the URL).

y S end a request to your sites identified as dynamic with an altered id= statementthat adds an extra quote to attempt to cancel the SQ L statement (e.g., id=6').

y P arse the response sent back to look for words like " SQ L" and "query"whichtypically indicate that the A PP is often sending back detailed error messages (abad sign).

y Review whether the error message indicates that the parameter sent to SQ Lwasn't encoded correctly (in which case, the site is open to SQ L injection attacks).

H ow Do You Protect Yourself?

SQ L injection attacks are something you need to worry about regardless of the webprogramming technology you're using (all web frameworks need to worry about it, infact). Here are a couple of very basic rules you must always follow:

1. Don't construct dynamic SQL statements without using a type-safeparameter encoding mechanism. Most data A PI s (including ADO + ADO.NET)have extra support that allows you to specify the exact type of parameterrequired (e.g., string, integer, and date) and can ensure that they are encoded tospecifically avoid hackers trying to exploit it. Always use the se features. Forexample, using ADO.NET with dynamic SQ L will allow you to rewrite the code likeso:

Dim SSN as String = Request.QueryString("SSN") Dim CMD As new SqlCommand("SELECT au_lname, au_fname FROM authors WHERE au_id = @au_id") Dim param = new SqlParameter("au_id", SqlDbType.VarChar)

param.Value = SSN cmd.Parameters.Add(param)

This will prevent someone from trying to sneak in additional SQ L expressions (since theADO.NET above knows how to string encode the AU_id value), and avoid other dataproblems (incorrectly typecasting values and the like). Note that theTableAdapter/Data S et designer built into the V S 2005 uses this mechanismautomatically, as do the A S P .NET 2.0 data source controls.

One common misconception is that if you are using S P ROCs or an ORM, you arecompletely safe from SQ L injection attacks. This isn't trueyou still need to be careful

8/8/2019 Identifying SQL Injection Vulnerabilities

2/2

when you pass values to a S P ROC. and/or when you escape or customize a query with anORM, you should do it in a safe way.

2. A lways conduct a security review of your application before putting it inproduction. Furthermore, you should also establish a formal security process toreview the whole code anytime you make updates. This later point is superimportant. Too often, I hear of teams that conduct a really detailed securityreview before going live, then have some "really minor" update they make to thesite weeks/months later where they skip doing a security review (" I t's just a tinyupdatewe'll code review it later"). As much as possible, always do a securityreview or double-check just to be on the safe side.

3. N ever store sensitive data in clear-text within a database. My personalopinion is that passwords should always be one -way hashed ( I don't even like tostore them encrypted). The A S P .NET 2.0 Membership A PI does this for youautomatically and by default (it also implements secure S ALT randomizationbehavior).

I f you decide to build your own membership database store, I 'd recommend checking outthe source code for our own membership provider implementation that we publishedhere. Moreover, you should make sure to encrypt credit card numbers and other privatedata in your database. This way, even if your database is compromised, at least yourcustomer's private data can't be exploited.

4. M ake sure to write automation unit tests that specifically verify your dataaccess layer and application against SQL injection attacks. This is great forsafeguarding against the " I t's just a tiny update, so I 'll be safe!" scenario, and iteven provides an additional safety layer that prevents you from accidentallyintroducing a bad security bug into your application.

5. Lock down your database to grant the web application accessing it theminimal set of permissions that it needs to function. I f the web applicationdoesn't need access to certain tables, then make sure it doesn't have permissionsto them. I f it is only generating read-only reports from your account payablestable, then make sure you disable insert/update/delete access.