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:
Not a problem when using parameterized stored procedures.
I'm just saying'..........
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!
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.
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?
Check out xkcd's take on this : http://xkcd.com/327/rio
Check out xkcd's take on this :
Parameterized SQL **is** the silver bullet against SQL injections. The stored procedures' exec problem argument can't dispute that.
DROP Blogposts
Post a Comment