Http Parameter Pollution

Http Parameter Pollution (HPP) is a new attack technique that was publicly announced only a few months ago. HPP is so simple, I'm amazed no one caught it sooner. When an application submits data to a server in the form of parameters, the server might not handle the situation gracefully when a parameter occurs more than once. In other words, if you put productid into the GET string twice, you might blow up the application (Figure 5). I love this class of vulnerability for one simple reason: it involves interactions between web servers, which all appear to behave in strange and often unexpected ways, and web applications (your guess as to how they react to mangled parameters is as good as mine). As far as I can see, there is no "correct" way to handle multiple parameters. Good arguments can be made for only taking the first one, the last one, concatenating them together, and even passing them as an array instead of the expected string type. Therefore, it is unlikely that the world will see a good long-term solution [17].

Figure 5: Http parameter pollution with the Apache web server.

Local File Inclusion

Most applications make use of include files (CSS files, libraries, etc.), and oftentimes they can be tricked into including files elsewhere on the system. Browsing the file system, especially remotely, gives an attacker detailed information, for example, by checking the /etc/ directory (for configuration files), the man page directories (for installed software and version information), and the binary and library directories. Because most web applications run when requested, any configuration information they need must be available to them; configuration files such as wp-config.php, config.inc.php, or LocalSettings.php allow attackers to retrieve the database credentials remotely.

Creating Files with MySQL

If an attacker is unable to execute code on the system but has access to the database (either through SQL injection or by harvesting credentials from a configuration file), what's the worst that can happen? Well assuming they don't simply wipe the database or delete large chunks of it, they can create files on the system by using the INTO OUTFILE SQL command. Fortunately, an attacker cannot overwrite existing files; otherwise, they'd be able to modify or destroy every database on the system!

However, with the use of INTO OUTFILE with custom-made database content, an attacker can create script files in the /tmp directory – for example:

CREATE TABLE `database`.`scripts` (`contents` TEXT NOT NULL) ENGINE = MYISAM
INSERT INTO `database`.`scripts` (`contents`) VALUES ('#!/bin/bash\necho "hello world"');
SELECT * INTO OUTFILE "/tmp/bad.sh" from `scripts` WHERE 1

An attacker can even create binary files by using the DUMPFILE command, letting the attack leverage local file inclusion bugs via image files or documents containing buffer overflows.