Wednesday, February 11, 2009

Why You Should Always Validate Your Input

Malicious folks are out there. They want to hurt your software. You’d better do everything you can to keep those little b*#!&@rds away from your stuff.

Look at this shot of a user at Udaloo, a nifty Twitter companion services that graphs stuff for you.

This user was obviously trying to send garbage to Udaloo in the hopes of making it do Something Bad. If you’re not up on SQL injection attacks then you need to stop reading this post and go brush up on them. I mean it. Stop now, go hit the books.

In case it isn’t clear, this user sent a Tweet to @uladoo with some malicious content in it in hopes of having the Uladoo drop the table ‘users’ from their database. I’m guessing Uladoo has their act together, or at least they don’t have a table named ‘users.’

Maybe the guy is associated with Udaloo, maybe not. Don’t know, don’t care, because this is a great demonstration of the critical need to make sure you have your act together when dealing with user input.

There are jackasses out there. Protect your stuff.

8 comments:

blindman said...

Not a problem when using parameterized stored procedures.
I'm just saying'..........

David Christiansen said...

That's cool you noticed this attempt Jim. Fortunately, it was one of the guys at Atomic Object (my development partners in uladoo.com) who did it, but it was malicious in intent. He suspected we weren't watching for evil geniuses and thought he would teach us a lesson. Neener neener!

Jim Holmes said...

Flippantly throwing out "parameterized stored procedures" as a silver bullet is dangerous and complete crap.

References for defense in depth:
http://is.gd/jhMS
http://is.gd/jhNm
http://is.gd/jhNt

Every one of those references speaks to defense in depth, and a couple give examples of where bad input can defeat even parameterized sprocs.

Sprocs alone don't solve everything.

Steve Owens said...

I did not read them all in depth, but I only saw one example where a parameterized query into a sproc caused mischief:

CREATE PROCEDURE dbo.RunQuery
@var ntext
AS
exec sp_executesql @var
GO

Yeah, that's an example. Is it good one? Hardly. It only illustrates another way to do inline SQL.

Other than that, is there a way to defeat a real-world parameterized query?

akarkera said...

Check out xkcd's take on this : http://xkcd.com/327/rio

akarkera said...

Check out xkcd's take on this :

mario said...

Parameterized SQL **is** the silver bullet against SQL injections. The stored procedures' exec problem argument can't dispute that.

Jef Claes said...

DROP Blogposts

Subscribe (RSS)

The Leadership Journey