Developers: Check Your %*^& Inputs

Better watch where you click, you just may be stepping into a Web page with a Trojan horse, according to security researcher Dancho Danchev.

This warning brought to you by the fact that developers continue to neglect to check their application -- and in this case, search engine -- inputs.The more things change, the more they stay the same. It's a cliché, I know.

But as I'm researching the details of an emerging class of attack, called SEO poisoning, I notice an old-school mistake: failure to validate input values.

To over simplify the issue, every application accepts inputs. The input could be a field for your Social Security number (be careful ...), or a Web form that collects your address and credit card (again, be careful ...) information. Many developers assume that us users will enter our credit card or Social Security number just as you're supposed to: 123-45-6789.

Bad assumption.

A hacker may attempt to crack an application, or Web site, by inserting gibberish into the field: Like #$%-$%-^&*) for a Social Security number.

What does the application do when presented with this nonsense?

The properly designed and sustainable program will respond with something like:

"That doesn't look like a valid Social Security number to me. Try again."

It does this because the developer made sure to validate that any information fed into that field is at the very least a series of seven numbers -- no other characters are allowed.

Now, the poorly designed application, where the inputs aren't checked, may start acting funny. It could crash, become unstable for a short enough time to allow the injection of unauthorized code (aka Trojan horse). The application may even go berserk, or begin to act like the A.I. Hal in the movie 2001: A Space Odyssey and start killing people so it can complete its mission. Though we may not have to worry about that threat until sometime after 2049.

Back to SEO poisoning. Security researcher Danchev is tracking an ongoing IFRAME injection attack at a number of highly ranked Web site pages. Basically, attackers are leveraging the IFRAME attack to insert Trojans onto cached Web pages.

As an innocent Web surfer, when you click on one of these well-placed Web pages, you get nailed with a Trojan horse that tracks who-knows-what on your system, and probably sends it to the who-knows-where crime syndicate.

Here's a tidbit from Danchev's findings:

"the IFRAME injection entirely relies on the lack of input validation within their search engines, making executable code possible to submit and therefore automatically execute upon accessing the cached page with a popular search query."

All of this nonsense could be avoided through a simple best practice known as input validation.

More information on the IFRAME attack can be found at Danchev's blog.