Tony Davis

Simple-Talk Editor
News, views and good brews

Bad Database Security

Published Tuesday, April 29, 2008 7:08 PM

The Daily WTF recently reported that the Sexual and Violent Offender Registry of Oklahoma had to shut down its website for 'routine maintenance'. It turns out that this routine maintenance was necessary because 10,597 social security numbers from sex offenders had been downloaded, by SQL injection.

 

Sadly, this is not an isolated case. There has been a recent spate of SQL injection attacks, most of which have been blamed on IIS. However, closer inspection, in this case, reveals that the JavaScript file responsible was merely testing for all the well-known security loopholes, many of which are open due to poor database security.

 

SQL injection attacks rely on several fundamental, but frustratingly common mistakes:

 

  1. Allow the end-user or the logins assigned to the website direct access to the base tables.
  2. Perform inadequate checking of input (inadequate type handling, incorrectly filtered escape characters)
  3. Perform no parameterisation of input in the calls to the database.

Without wishing to re-open an old debate, Simple-Talk has long advised that the interface between the application and the SQL Server database should always use stored procedures. However, many are still resistant to the idea.

 

The attacker who is out to get data also needs to have it delivered on-screen, as was conveniently provided in the Oklahoma incident. Database errors should never be displayed on-screen in a production system. On the contrary, all errors, even 404 errors, should be logged and emailed to production staff as part of the general alerting system for any corporate application.

 

No longer can developers sit back in their chairs once an application is shown to perform to specification. They must prove that their application can counter all current security threats and be able to report when an attack happens. When implemented, you may be shocked by the vast number of attempted intrusions to which the typical application is subjected.

 

As always, your views are encouraged. Add your comments to this blog and the three best entries will win a Simple-Talk gift pack, complete with polo shirt and much-coveted USB dongle.

 

Cheers,

Tony.

Comments

 

tmitch said:

I've found this vulnerability to be all too common.  My opinion is that many of these vulnerable web apps are written as a quick-and-dirty solution to a small problem, or perhaps developed as a proof of concept.  As interest/usage in the app grows, the emphasis is to add features rather than test and verify the parts that are already working.  Slowly but surely, this tiny little web application becomes a very visible part of your public-facing web site, and sooner or later the vulnerability will reveal itself (read: you're gonna get hacked).
April 29, 2008 4:06 PM
 

Ron Dameron said:

Tony,

I agree totally that stored procedures are the preferred method of database access.

Check out http://xkcd.com/327/ for a laugh about SQL Injection.

April 29, 2008 8:11 PM
 

Granted said:

Speaking of security, one of the new trends that's coming like a freight train is ORM (Object Relational Mapping). This includes tools like nHibernate & LINQ. LINQ is being pushed very heavily from Microsoft. nHibernate is a .NET port of the most popular ORM Java tool, Hibernate. Both these, when used straight out of the box and taking advantage of their full functionality, require table level access to the database. Yes, they will permit you to use stored procedures, but it's at the cost of considerable amounts of the functionality that each tool provides.

The only ray of sunshine in this cloud is that the tools generate parameterized queries. I have yet to see an example of an injection attack through one of those.

The developers at our company are very excited about the idea of getting rid of TSQL and using these tools. None of the DBA's are excited about reducing the level of security on our databases. More and more databases are going to be exposed through the use of these tools, especially LINQ, so the process of securing databases just got harder.
April 30, 2008 6:44 AM
 

paulh said:

IMHO this is a prime example of the value a good DBA adds to a project!

I have worked on sites which have been previously created by web programmers (who I respect as specialists in their own right) who have implemented quick and dirty SELECT statements to enable login. Their immediate problem is solved, and the code gets buried inside a system, sometimes inside a hard-to-find config screen in a CMS package. The code is eventaully left live in the system after launch.

It is a shame when it takes an embarassing incident to highlight thesecurity  vulnerability. By incorporarting some DBA time into the project at an early stage there are cost and reputation savings to be made.
April 30, 2008 7:24 AM
 

bferguson said:

I agree that most (if not all) T-SQL should be in stored procedures or functions.  However, I also feel that it is the repsonability of the application dba to teach the developers how to secure their t-sql code, and the developers should at least give the dba an overview of the application and a primer in coding applications.  I am a web developer, database developer, dba and architect.  I know the value of at least knowing the 'other' side.  While a DBA may not be able to code a compelte application, they should at least know the concepts, same goes for the application developer.  

Some of the best DBA's I know are also application developers and some of the best developers are also DBA's.



April 30, 2008 7:55 AM
 

jtklopcic said:

The main reason I hear from people about not using stored procedures is that they are trying to isolate "business logic" from "business data", or in MVC parlance, trying to isolate the Model from the Controller.

IMHO, this is shortsighted.  A properly designed database should be treated as a independent tier in an n-tier system.  It's not just a data store -- it's a full-fledged application, with a well-defined API, security model, and performance requirements.  And if there are good reasons (performance, encapsulation, whatever) for including some business logic in the database tier, then that is where it belongs.
April 30, 2008 8:26 AM
 

Jack the DBA said:

As Granted has commented ORM is becoming commonly used and, while it does offer some advantages, it does discourage use of stored procedures.  While most use parameterized queries to protect against sql injection, they still require granting table level access which is no-no IMHO.  I realize that in some situations, search in particular, dynamic sql requiring table level access may be necessary, these are the exceptions and NOT the rule.

bferguson is correct that DBA's need to be teaching developers how to secure their SQL code, but anyone with any professional ability should know about SQL Injection and how to defend against it.  We, developers and DBA's, need to be able to have an open and non-confrontational dialogue about these issues/  All too often one or both sides refuses to actually consider the other's position to the detriment of the industry.
April 30, 2008 10:10 AM
 

paschott said:

I have a problem putting everything into a stored procedure because sometimes the logic required to make an efficient stored procedure is a little over the top and will result in poor performance.  Using an ORM solution makes sense at those times.  (And I really hate saying that as a DBA. :) )

Still, we need to secure whichever solution is used and the example listed above is a great reason to do so.  It's a shame that nobody will know whether or not the records in the system are valid and were real entries/updates.  Hopefully this wasn't a widely known exploit before it was fixed.
April 30, 2008 12:21 PM
 

Raju said:

It is strange that even after so many years of software, validations are neglected leading to poor software with security loopholes
May 2, 2008 2:16 AM
 

Mudu’s Blog » Stored Procedures said:

May 5, 2008 5:13 AM
 

Daniel Penrod said:

Protecting against SQL injection can be as simple as putting a maxlength on your text fields, using .NET and taking advantage of its postback model.  Using stored procedures will always provide added protection because the logic is in the procedure, not the web application, so you can't "DROP" a database via the web app.
May 5, 2008 8:04 AM
 

TadRichard said:

I totally agree that a security layer needs to be between the database and the rendering code.  For for 'login' and other types of 'common' procedures, using SPs is a good practice.  But the problem I've experienced with stored procedures is the inability to generalize the code into a resusable library across varied schemas.  New stored procedures enevitably need to be created for every project.

And, even using stored procedures, web developers have access to database credentials (although hopefully restricted well below sa level); which is a bad thing, imho.

What we've done to try to address the issue is to create a SQL processing layer in a DLL that hides the database connection information from the web developers.  All SQL statements must be passed through this layer -- its the only access to the database --- and it validates the SQL looking for injection attacks, etc., before passing the commands to the database.

It's not a foolproof solution -- we do need to constantly be looking for vunerabilities -- but it does provide for a security level that is much more cost effective (for us) than using stored procedures everywhere.
May 7, 2008 9:38 AM
 

MVV said:

A lot of supposely serious websites are in fact pretty much crying to get hacked. A lot of untrained people are putting up online systems they don't know nor care to make fast bucks, using software that is all fine and good for a small club or internal use only to the wild wide web

I have lost track of system where the SQL server has tcp/ip connectivity open , sa user active without password or even with "sa" as password , serving web sites put together with spit and duct tape. They were even willing to set up online shops, without changing not a iota of their setup. The fast one that put their web online is missing or unreachable , and the management is blind to the risks of internet , they only get lulled by the chants of one more buck coming via web..sad but true , they are kids with guns..pointing at their own chests. Any talk about firewalls , reduce surface of attack , cut privileges , ..like ducks and water.

We cannont be shepherds when the sheep call the wolves to their homes :(
May 9, 2008 9:36 AM
 

meklembl2 said:

You know how it is.  You keep preaching the "good" way.  Use stored procedures, no in line sql calls, lower the privileges of users in production systems, be consistent in your setup routines, keep your room clean (oh I digress, maybe).  Overall, you start to get tired of preaching, as you think the audience is getting tired of the speach.  Remember, it's not easy being correct, but it's necessary to continue to forge good habits.
May 15, 2008 7:46 AM
 

nigelrivett said:

A number of factors tend to cause this:

Managers seeing the task as just a client application and so puting all the design in the hands of application developers.
Application developers thinking that it's good to be able to access and control everything in the database from the application.
Application languages and SQL Server being so easy to get something working that developers think it's easy to complete the task.
Companies thinking they can get away with using inexperienced staff to write systems.
May 20, 2008 11:43 PM
You need to sign in to comment on this blog

















<April 2008>
SuMoTuWeThFrSa
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910
Monitor your Database Backups Using Operations Manager
 Thomas LaRock shows just how easy it is for a DBAs to monitor any aspect of the databases in their... Read more...

Verity Stob: Geek of the Week
 Real geeks read Verity Stob. Verity writes her painfully funny invective from a powerful advantage, she... Read more...

SQL Server Index Basics
 Given the fundamental importance of indexes in databases, it always comes as a surprise how often the... Read more...

Managing Exchange 2007 Mailbox Quotas with Windows PowerShell
 The use of PowerShell with Exchange Server 2007 can do a great deal to ease the task of managing... Read more...

Optimizing Exchange Server 2007
 Brien Posey ponders an 'off the cuff' remark that Exchange 2007 runs so well with a default... Read more...