"The rogue URL horns its way onto web pages through a SQL injection vulnerability in IIS and possibly other web servers, according to IT-related web forums."

Um...now, now.. lets not start another IIS blamefest here, if you'd bothered to read more widely you'll find that the attack vector is badly written user script that doesn't bother with any sort of input hygene before passing off to SQL.

And rightly as mentioned here:

http://isc.sans.org/diary.html?storyid=3823

We'll probably start seeing this infection breeding on LAMP stacks pretty soon.

Any script on any server that blindly trusts input and passes it back to SQL, MySQL, Oracle, whatever is going to get dirty sooner or later, not just stuff running on the MS stack.

Paris, because I bet even she's got better hygene standards than the script monkeys who cobbled together the affected sites.

"SQL injection vulnerability in IIS" -- ahh, excuse me? Since when does IIS have anything to do with SQL injection?! The blame is entirely on the application that runs under IIS, Apache, or any other web-server. Cheap shot Reg.

Only a fool would go there and any fool who does deserves what they get.

Followed by Cleanup Wednesday, I suppose…

Please include the following simple lines of code at the start of your CGI scripts (PHP will be similar):

for $key ( $cgi->param() )

{

$input{$key} = $cgi->param($key);

$apos = q{#}; $quot = q{"}; $opren = q{(}; $cpren = q{&#41}; $intr = q{?}; $astr = q{&#42}; $lt = q{<}; $gt = q{>}; $amp = q{&}; $eq = q{&#61}; $semi = q{&#59;};

$input{$key} =~ s/\'/$apos/g; $input{$key} =~ s/\"/$quot/g; $input{$key} =~ s/\(/$opren/g; $input{$key} =~ s/\)/$cpren/g; $input{$key} =~ s/\?/$intr/g;

$input{$key} =~ s/\*/$astr/g; $input{$key} =~ s/\</$lt/g; $input{$key} =~ s/\>/$gt/g; $input{$key} =~ s/\&/$amp/g; $input{$key} =~ s/\=/$eq/g; $input{$key} =~ s/\;/$semi/g;

if (($input{$key} ~= /DELETE\s+FROM/i) || ($input{$key} ~= /SELECT\s+\D+\s+FROM/i) || ($input{$key} =~ /UPDATE\s+TABLE/i) || ($input{$key} =~ /INSERT\s+INTO/i) || ($input{$key} =~ /TRUNCATE\s+TABLE/i))

{

$input{$key} = q{};

}

}

Now use only the %input hash for processing your input parameters. This code snippet escapes all the HTML, Javascript and SQL control and delimiter characters, rendering any attempted code injection into garbage that will merely display as literal text instead of executing on your server or in the viewer's browser. Further, any direct SQL commands submitted as input that modify the database are detected and erased. More subtle SQL injection (eg ' OR 1 = 1) used to bypass login authentication breaks because characters like the apostrophe and equals sign are escaped, causing an SQL error. And Javascript will break both because a) the HTML script tags required to embed it are escaped, and b) the end-of-line semicolons required in Javascript are also escaped.

It's not rocket science, and it doesn't require a million-dollar security solution. Always parse your input before exposing your database to it, that's all. The above code does exactly that, and you can have it for free! :)

I am wondering if this may be related to the spam surge in the last 24 hours or so. At least I have been receiving tons of spam emails (and still am).

Looks like an exploit to me.....

Back in 2000 I wrote a site with a valnerability. It used IIS and MS Access back end. It was simple to type code into the user login box that the server interpreted as IF PASSWORD=PASSWORD THEN OPEN DOOR

The thing was that company policy was against IIS and MS Access so another programmer re-wrote it in Apache, Oracle and Java. The funny part was that this valnerability still happened but with slightly altered syntax!!!

Surely everyone passes any user input through a function to clean up the string before processing? I thought this problem was old in 2000 since you are supposed to check inputs before acting on them.

Please use parameters in your queries, instead of lame quoting mechanisms all invariably at risk when dealing with unicode...

Paris because she knows to deal with raw data

Looking through the first few pages on google for "nihaorr1", it looks like they might have deliberately targeted older classic asp code. which I would expect to contain a higher percentage of vulnerabilities than more modern code.

This isn't really SQL injection, as if you stored the data in a file you'd have the same problem. This is to do with cleaning your input and much as I've become irritated with Microsoft I don't think one can really single them out for blame.... this time :-)

I've got an even better idea: lets not use parameters as they make the debugging process take twice as long and the code read like crap; instead let's use a standard, decent quoting function that handles unicode, nulls, etc. I'm looking at you PHP.

FFS Taint mode! At least during dev.

perldoc perlsec /taint

@Mark - I agree completely

@The AC Bashing Mark - Does your client(s) know you are more bothered about your life being easier than making his / her site secure from malicious attacks?

PHP has mysql_real_escape_string() which takes a lot of typing...

Maybe it would be better if web programming languages did escaping by default to variables got through forms and only presenting the dangerous unescaped version if specifically requested?

Paris because I'm sure all her inputs are safe and verified.

#!/usr/bin/perl -Tw

use CGI;

use strict;

And remember CGI is not just Perl.

Unless that code has come from the CGI module I would be quite dubious of its ability to stop all injection attacks.

There is unicode, now :)

Really you should pass all the sql code via parameters as well, and not a bad idea to offer only access to functions in the SQL, that makes it a little harder to work out what to attack, if any of the other levels have holes.

Oh dear someone is advising you don't pass as params, that is a bad idea, ride'm cowboy.

Escaped to what though? The danger depends what you're going to do with it.

E.g. In JonBsh (my default shell - perhaps) anything escaped &#...; is treated as the character is represents, so that escaping wouldn't help when I recklessly interpolate a var as a parameter to a shell command..

By reducing the risk people stop being aware of the risk.

What's needed is a mode that highlights the use of "tainted" variables that have data from potentially insecure sources and forces the programmer to "untaint" them - perhaps, a "taint" mode?

I'm sure we could debug the code for @Steve Roper. Whether it's the simple ~= should be =~ or the fact that the double quote character " is transformed into the bizarre string &amp&#59;quot&#59; or that the quote character ' is transformed into a hash symbol #.

This code is fundamentally flawed and is an example of how it is too easy to write a bit of code and believe you are safe. If you are going to filter the input like this then you should allow data that is known to be safe and remove or modify everything else. As we can see from this example, single quotes and double quotes are included but not back-tick. Round brackets are included but not square or curly brackets. What about at or dollar or percent or double hyphen that can have special meaning. The list goes on.

I've seen sites that try to use mechanisms like this. The CEO has to deal with complaints when Mr O'Connor can't book tickets because his name has been garbled.

@umacf24 You are correct. This is an exploit.

@Mark Flingstone - I agree completely.

,, me putting "nihaorr1.com" as a bogus entry in my hosts file, or am I misunderstanding how this works?

Some of us have SQL injection in hand. See

http://httpd.apache.org/docs/2.3/mod/mod_dbd.html#security

Possibly, very dependent if the nihaorr1.com is the site that delivers the payload, and why have people not learnt how to program and sanitize code for SQL yet, this has been a major security issue for years....

As for SQL injection in IIS... this is more of a php/asp/jsp issue (and code obviously), however a fix could be put in place at a code level, interrupter or daemon level to avoid mishaps like this.

Actually in PHP it's more like

strip_tags(mysql_real_escape_string($strInput, $dbConn))

Of course in reality you'll do something a little more sophisticated than that and bolt it into your database query object, make the methods of that object protected and only call them through pre-defined extensions ensuring that users cannot directly interface with your database layer at all.

In this case Mr O'Connor should have no problems - so long as you remember to stripslashes on any data you're retrieving from the database.

>> strip_tags(mysql_real_escape_string($strInput, $dbConn))

I would have thought that depends on what you want to do with the data your are storing. Perhaps you want it to contain HTML/PHP tags, or a subset. Strip_tags might sometimes be more useful before you output the data. There are many web apps which use a database to store HTML data.

>> Of course in reality you'll do something a little more sophisticated than that and

>> bolt it into your database query object, make the methods of that object

>> protected and only call them through pre-defined extensions ensuring that

>> users cannot directly interface with your database layer at all.

I don't understand who your users are; that they are not allowed access to your database layer, but have access to your objects. Are your users developers? I don't understand.

And another problem, Steve:

The MySQL syntax is

INSERT [INTO]

i.e. your code will miss any INSERT queries that don't use the INTO part.

This is voodoo programming, and it will get you in the end.

@Dennis

I knew it, you're all still racist against the Paddies, aren't you?

get desktop linux - stop worrying about this nonsense!

PHP has this already, it's called Magic Quotes. The idea is that quote-ish characters submitted through forms get a backslash already prepended to them and are thus safe to pass to other applications such as MySQL.

It's enabled by default in some PHP versions, disabled by default in other versions, and the proper way of finding out whether it's on or off varies from version to version. To complicate matters further, some Linux distributors helpfully change the defaults as compared to the "official" Source Code distributed by the PHP project. There's an *im*proper way of finding out whether magic quotes is turned off or on, but that is still vulnerable to a more determined hacker and so shouldn't be used.

Oh, and just to make things even more fun, every hosting company sets their system up differently .....

U missed one.

Enter name: [Sucker";drop database;"]

"I knew it, you're all still racist against the Paddies, aren't you?"

And I'm also prejudiced against the people of Kent who travel to the station Bat & Ball. And the residents of Robin Hood’s Bay in Yorkshire. And Davidson’s Mains area of Edinburgh. And Adam’s Green, Dorset.

Mine's the one with the gazetteer in the pocket.

s/([^\w\s])/'&#'.ord($1).';'/eg;

Surely these sites could be owned when Bobby Tables registers, as his full name is:

Robert'); DROP TABLE Students; --

I'd give the xkcd link, but I'm too lazy to do it now.