Neglecting to review and sanitize user-provided data at every opportunity could provide attackers the opportunity to do massive internal damage to your application, data, and server, and even steal the identity of unsuspecting site users. This section shows you just how significant this danger is by demonstrating two attacks left open to Web sites whose developers have chosen to ignore this necessary safeguard. The first attack results in the deletion of valuable site files, and the second attack results in the hijacking of a random userís identity through an attack technique known as cross-site scripting. This section concludes with an introduction to a few easy data validation solutions that will help remedy this important matter.
To illustrate just how ugly things could get if you neglect validation of user input, suppose that your application requires that user input be passed to some sort of legacy command-line application called inventorymgr that hasnít yet been ported to PHP. Executing such an application by way of PHP requires use of a command execution function such as exec() or system() . The inventorymgr application accepts as input the SKU of a particular product and a recommendation for the number of products that should be reordered. For example, suppose the cherry cheesecake has been particularly popular lately, resulting in a rapid depletion of cherries. The pastry chef might use the application to order 50 more jars of cherries (SKU 50XCH67YU), resulting in the following call to inventorymgr :
$sku = "50XCH67YU";
Now suppose the pastry chef has become deranged from sniffing an overabundance of oven fumes and decides to attempt to destroy the Web site by passing the following string in as the recommended quantity to reorder:
50; rm -rf *
This results in the following command being executed in exec() :
exec("/opt/inventorymgr 50XCH67YU 50; rm -rf *");
The inventorymgr application would indeed execute as intended but would be immediately followed by an attempt to recursively delete every file residing in the directory where the executing PHP script resides.
The previous scenario demonstrates just how easily valuable site files could be deleted should user data not be filtered. While itís possible that damage from such an attack could be minimized by restoring a recent backup of the site and corresponding data, it would be considerably more difficult to recover from the damage resulting from the attack demonstrated in this section because it involves the betrayal of a site user that has otherwise placed his trust in the security of your Web site. Known as cross-site scripting, this attack involves the insertion of malicious code into a page frequented by other users (e.g., an online bulletin board). Merely visiting this page can result in the transmission of data to a third partyís site, which could allow the attacker to later return and impersonate the unwitting visitor. Letís set up the environment parameters that welcome such an attack.
The logger.php file might look like this:
<?php // Format variable in easily accessible manner $info = "$cookie\n\n";
// Format variable in easily accessible manner $info = "$cookie\n\n";
// Write information to file
// Return to original site
Provided the e-commerce site isnít comparing cookie information to a specific IP address, a safeguard that is all too uncommon, all the attacker has to do is assemble the cookie data into a format supported by her browser, and then return to the site from which the information was culled. Chances are sheís now masquerading as the innocent user, potentially making unauthorized purchases with her credit card, further defacing the forums, and even wreaking other havoc.
blog comments powered by Disqus