SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

SQL Injection... is this still a problem?

For some reason, today I came across at least a half-dozen blog posts and articles about how to avoid SQL injection attacks.  It had been a while since I had read about SQL injections, and an odd thought comes to mind:

Why is SQL injection still an issue?

This is such an easy problem to get around.  The use of stored procedures or parameterized queries will wholly eliminate this threat, and is just as easy (in many cases, easier) than building dynamic SQL.  I have a no-exceptions rule that I never allow dynamic SQL in production code.  I have built a few prototypes for demonstration purposes that use dynamic SQL, but in those cases I usually want to actually demonstrate the SQL query as much as the app itself.  For live systems, using stored procedures prevents these attacks and can yield some performance gains as well by persisting the execution plan.  If you require more flexibility, you can use parameterized SQL from .NET applications.

Please forgive this soapbox rant about this issue, but it seems pretty clear to me.  Smoking causes cancer, drinking and driving causes death, and dynamic SQL causes injection attacks.  All three are bad and completely avoidable.

Tim Mitchell

Tim Mitchell is a business intelligence consultant, author, trainer, and Microsoft Data Platform MVP with over thirteen years of data management experience. He is the founder and principal of Tyleris Data Solutions.

Tim has spoken at international and local events including the SQL PASS Summit, SQLBits, SQL Connections, along with dozens of tech fests, code camps, and SQL Saturday events. He is coauthor of the book SSIS Design Patterns, and is a contributing author on MVP Deep Dives 2.

You can visit his website and blog at TimMitchell.net or follow him on Twitter at @Tim_Mitchell.


Posted by Richard on 16 October 2006
Stored procedures will not prevent SQL Injection problems unless they are used properly.

For example, this psuedo-code would be open to SQL Injection:

query = "exec GetData @UserName='" + name + "'"

Whereas this wouldn't:

query = new Command()
query.Text = "exec GetData @UserName = @UserName"
query.AddParameter("@UserName", name)
Leave a Comment

Please register or log in to leave a comment.