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.

Risk

3/12/2008
11:45 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
9 Tips to Prepare for the Future of Cloud & Network Security
Kelly Sheridan, Staff Editor, Dark Reading,  9/28/2020
Attacker Dwell Time: Ransomware's Most Important Metric
Ricardo Villadiego, Founder and CEO of Lumu,  9/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
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
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15488
PUBLISHED: 2020-09-30
Re:Desk 2.3 allows insecure file upload.
CVE-2020-15849
PUBLISHED: 2020-09-30
Re:Desk 2.3 has a blind authenticated SQL injection vulnerability in the SettingsController class, in the actionEmailTemplates() method. A malicious actor with access to an administrative account could abuse this vulnerability to recover sensitive data from the application's database, allowing for a...
CVE-2020-14375
PUBLISHED: 2020-09-30
A flaw was found in dpdk in versions before 18.11.10 and before 19.11.5. Virtio ring descriptors, and the data they describe are in a region of memory accessible by from both the virtual machine and the host. An attacker in a VM can change the contents of the memory after vhost_crypto has validated ...
CVE-2020-14376
PUBLISHED: 2020-09-30
A flaw was found in dpdk in versions before 18.11.10 and before 19.11.5. A lack of bounds checking when copying iv_data from the VM guest memory into host memory can lead to a large buffer overflow. The highest threat from this vulnerability is to data confidentiality and integrity as well as system...
CVE-2020-14377
PUBLISHED: 2020-09-30
A flaw was found in dpdk in versions before 18.11.10 and before 19.11.5. A complete lack of validation of attacker-controlled parameters can lead to a buffer over read. The results of the over read are then written back to the guest virtual machine memory. This vulnerability can be used by an attack...