Commentary

George Hulme
 

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.

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.


More Security Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links