Twelve Monkeys, I think you'll find.

I love the way John has linked to a page all about the film, yet still manages to misspell the films title!

If you use stored procedures and don't give the web site user access to the raw tables there can be no SQL injection!

Spelling and Punctuation karma, surely? ;)

</pedant>

Not true.

Injection can work by using a input value that is displayed (without sanitizing it).

Say you had a comments application, that had three inputs: Title, Author, and Comment. And say when you press submit on the entry form the input values are stored verbatim, when the comment is displayed, say the author field just has "by " added to the beginning and is sent to the browser. Now say, someone inputs a script tag as the author, the browser will, instead of displaying the author, run the script.

Stored procedures does protect you from someone replacing a password input with a SQL script select statement to get the password from the database, assuming you can get enough details of the database structure from the error messages that appear in the browser (or it is a standard structure database).

@ Robert "little knowledge is dangerous" Forsyth

ROFL... read a book dude...what you describe would not be an SQLi... and..

"Stored procedures does protect you from someone blah blah blah....". Again, read a book

I shall remember to use apostrophes for possession.

I shall remember to use apostrophes for possession.

I shall remember to use apostrophes for possession...

And as Mark correctly pointed out, it was punctuation karma biting me on the arse :) (aka "Pedantry to the rescue!")

I've been scanning my sites for this..

The evidence for the malware I picked up, were malicious iframe's linked to javascripts appended to every index.html and index.php (even if the name started with something else)

grep -i -r -H -n --binary-files=without-match --colour=auto -U iframe /path/to/site/* > ~/tmp.txt && grep -i fromCharCode ~/tmp.txt > ~/results.txt

Just delete the iframe and script code to clean your code.. don't know how to prevent it though.. anyone?

"don't know how to prevent it though.. anyone"

1. sanitise user input on the way in

2. html encode it on the way out. most web languages have a function for this, e.g. php has htmlspecialchars

Yes, you're right, stored procedures protect the database from the user gaining unauthorised access to the data, but they don't necessarily protect you from people inserting html it entered values.

I take it you've never seen a proc like this:

CREATE PROCEDURE [dbo].[myproc] @sql varchar(8000)

EXEC(@sql)

Moral of the story: _Anything_ can be misused / written badly / insecure

Hi John, it's me again ...

"With the benefit of the hacker tool used to pull off the attack this all becomes much clearer, much like it was easier for scientists to unravel a cure for the mystery pandemic that blighted mankind in the Twelve Monkies after they obtained a sample of the pure source"

No, the above is a description of an SQL injection exploit, the latter is a ludicrous plot from a movie ..

Like, why didn't they send him back before the outbreak with a very contagious antidote virus to the first virus, that way he would have innoculate the population in advance. That way, him getting amnesia for half the picture and wandering around wondering what to do, wouldn't matter.

Wait a minute, I have an idea, why don't SANS send someone back in time to get a sample of the original malware. I'm available and after a life time of overindulging in chemicals, is suffering from amnesia already, just wait a minute, who wrote that already, voodoo mannn ???

They tried to have James Cole kill the end-of-world microbiologist who originally released the viruses. Remember the airport scene? Cole was gunned down, and after one of the tubes had been opened.

You may want to look into mod_security

http://www.modsecurity.org/projects/modsecurity/apache/index.html