Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


11:45 PM
George V. Hulme
George V. 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.

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.


Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Browsers to Enforce Shorter Certificate Life Spans: What Businesses Should Know
Kelly Sheridan, Staff Editor, Dark Reading,  7/30/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-05
An issue was discovered in NLnet Labs Routinator 0.1.0 through 0.7.1. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X509 Certificate...
PUBLISHED: 2020-08-05
Jeedom through 4.0.38 allows XSS.
PUBLISHED: 2020-08-05
In Contour ( Ingress controller for Kubernetes) before version 1.7.0, a bad actor can shut down all instances of Envoy, essentially killing the entire ingress data plane. GET requests to /shutdown on port 8090 of the Envoy pod initiate Envoy's shutdown procedure. The shutdown procedure includes flip...
PUBLISHED: 2020-08-05
In Sulu before versions 1.6.35, 2.0.10, and 2.1.1, when the "Forget password" feature on the login screen is used, Sulu asks the user for a username or email address. If the given string is not found, a response with a `400` error code is returned, along with a error message saying that th...
PUBLISHED: 2020-08-05
Unexpected behavior violation in McAfee Total Protection (MTP) prior to 16.0.R26 allows local users to turn off real time scanning via a specially crafted object making a specific function call.