Q

Can a hacker actually post malicious scripts to any server using a drop-down list?

By viewing a page's HTML source code and writing malicious scripts to a drop-down list, hackers may be able to re-post the malicous page to the server. In this security threats expert response, learn how to avoid this attack.

A coworker was showing me how a hacker can save the 'view source' HTML of my Web page to the desktop, add a malicious script to my drop-down list, and possibly use that HTML page to post that script back to my server. Do you consider this a significant enterprise threat? Can a hacker actually post their scripts to my server via a method like this?
It's crucial for Web application developers and security personnel to realize that drop-down lists on Web sites don't limit the attacker's options for user input. Drop-down lists help improve human factors, but they aren't a security feature. Attackers can trivially add options to the drop-down list using a variety of techniques, such as the one you cite. Besides saving and editing the source of the Web page, another method is to use a Web application manipulation proxy like the stellar free Paros Proxy, which allows attackers to alter data in the HTTP/HTTPS session between a browser and the Web server.

For example, suppose a website asks users which country they live in. There might be a drop-down menu letting users choose from a hundred options or so. Some Web developers might think that they don't have to handle this input carefully, because they erroneously believe that attackers are limited to this enumerated list of options. But bad guys could add entries in their own browser to inject commands, database queries, buffer overflows...

and/or browser scripts into this one country drop-down field. Thus, drop-down lists aren't a form of user input filtering. To directly answer your first question, Web apps that were developed with the assumption that drop-down lists are a form of filtering are indeed a significant enterprise threat.

Referring to the second question, attackers can indeed use post methods to send scripts to a server via custom-created input in drop-down menu items. But, it's important to understand that other users on a website won't see the attacker-injected options in their view of the drop-down list. Only the attacker will have that option in the list, which will be sent to the target server. What happens then? If the Web application runs some command at a shell to handle the input; the user may be vulnerable to command-injection exploitation, in which the attacker piggybacks shell commands with user input, tricking the Web server into running commands.

If the Web application builds a query for a database using the variable value it collects, users could be vulnerable to SQL injections, where the attacker sends meaningful input to make the database perform queries or updates of its data. If the Web application doesn't properly manage the memory associated with its variables by checking the size of variables before moving them around, there may be a buffer overflow flaw, which could inject machine language code to run on the server. And, if the Web application sends the user input back to a browser, you could have a cross-site scripting (XSS) attack.

Web apps that store user input and later deliver it to another user are subject to stored XSS attacks. The bad guy can then inject scripts to run in these employees' browsers when they review the order at a later time. Web apps that merely accept user input and then send it directly back to the same user's browser are subject to reflected XSS attacks. With this kind of attack, the attacker can trick other users into sending scripts as user input to a target website, where it reflects back and runs in their browsers.

The point of all of these vulnerabilities and their related attacks is that they are based on improper validation of user input. Web developers need to be trained to avoid trusting what comes in from browsers, even if it comes from a drop-down list. Developers should write code that carefully filters out potentially malicious characters and verifies the size of all input received by the Web application.

More information

This was first published in May 2008

Dig deeper on Emerging Information Security Threats

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close