Is there any sense in worrying about SQL injection in a Winforms project?

views:

101

answers:

+2 Q:

Is there any sense in worrying about SQL injection in a Winforms project?

In SO and elsewhere it's nearly impossible to post long concatenated SQL instructions in sample code without someone politely pointing out that it's better to use parameterized input and stored procedures.

Recent example here.

But is it meaningful to worry about SQL injection in a Winforms project?

+1 A:

Yes it is, for all the reasons you've seen on other projects.

Your user base may be smaller but the same dangers are there.

Jay Riggs 2010-01-12 23:36:02

It isn't that the user base is smaller, it's more that the user base - typically - has an entirely different relationship with the database. Often it's in every sense "their" database. They have no desire to screw with it. In fact they own it.

hawbsl 2010-01-13 00:15:25

Do they own the backup procedure too?

Hans Passant 2010-01-13 00:32:09

SQL injection is not necessarily malicious, it could be an honest accident that happens to exploit the application's lax treatment of input.

Bill Karwin 2010-01-13 01:00:35

+3 A:

Is there some reason not to write safe database code? I don't think so.

Everyone should get into the habit of executing SQL safely, so you won't even have to think about it when you write public apps.

Also consider that a lot of code that's intended to be private will end up becoming accessible publicly months or years later. For example, "hey this intranet app for inventory reporting is useful, why don't we upload it to our public website for our business partners to use?"

Use parameters to separate unvalidated data from the SQL query.
You can interpolate validated data into SQL queries. That is, if you have code to test that a variable can only be an integer (for example), then it's safe to treat it as an integer.
For other dynamic parts of a query (table names, column names, expressions, etc.) you can't use query parameters. But you can map user input to hardcoded strings. E.g. if user enters 1, then sort by date column. If user enters 2 then sort by status column.
Ignore programmers who say "just use stored procedures!" as though that has anything to do with defense against SQL injection. It doesn't.

Bill Karwin 2010-01-12 23:52:08

+1; if you don't take care about SQL injection even in desktop applications, soon or later, "all your _data_base are belong to us"

Rubens Farias 2010-01-13 00:05:37

good point about private possibly evolving into public

hawbsl 2010-01-20 18:34:29

+2 A:

Epic tale from real life: the Big Boss of the mid-western company came to take a look at project progress. Not sure how it happened, but somehow a new set of orders came down from the scheduling office for a customer never seen before. And went into production around the time the Boss came to have a look. His last name was O'Shaughnessy.

Using parameterized input is good for more than just avoiding SQL Injection.

Hans Passant 2010-01-13 00:38:38

I think that does fit the definition of SQL injection, even though it's accidental instead of malicious.

Bill Karwin 2010-01-13 01:01:32

Good point, there is no real difference.

Hans Passant 2010-01-13 01:07:30

i guess my question should have distinguished between malicious and accidental. of course a winforms app has to guard against the latter. there are ways of protecting a winforms app from a "O'Shaughnessy" error which would still, in theory, leave it vulnerable to other kinds of attacks

hawbsl 2010-01-20 18:33:31

ansaurus

tags:

views:

answers:

Is there any sense in worrying about SQL injection in a Winforms project?

related questions