|
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
|
