19.09.2017 Views

the-web-application-hackers-handbook

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

358 Chapter 10 n Attacking Back-End Components<br />

Injecting OS Commands<br />

Most <strong>web</strong> server platforms have evolved to <strong>the</strong> point where built-in APIs exist<br />

to perform practically any required interaction with <strong>the</strong> server’s operating<br />

system. Properly used, <strong>the</strong>se APIs can enable developers to access <strong>the</strong> filesystem,<br />

interface with o<strong>the</strong>r processes, and carry out network communications in<br />

a safe manner. Never<strong>the</strong>less, <strong>the</strong>re are many situations in which developers<br />

elect to use <strong>the</strong> more heavyweight technique of issuing operating system commands<br />

directly to <strong>the</strong> server. This option can be attractive because of its power<br />

and simplicity and often provides an immediate and functional solution to<br />

a particular problem. However, if <strong>the</strong> <strong>application</strong> passes user-supplied input<br />

to operating system commands, it may be vulnerable to command injection,<br />

enabling an attacker to submit crafted input that modifies <strong>the</strong> commands that<br />

<strong>the</strong> developers intended to perform.<br />

The functions commonly used to issue operating system commands, such<br />

as exec in PHP and wscript.shell in ASP, do not impose any restrictions on<br />

<strong>the</strong> scope of commands that may be performed. Even if a developer intends<br />

to use an API to perform a relatively benign task such as listing a directory’s<br />

contents, an attacker may be able to subvert it to write arbitrary files or launch<br />

o<strong>the</strong>r programs. Any injected commands usually run in <strong>the</strong> security context<br />

of <strong>the</strong> <strong>web</strong> server process, which often is sufficiently powerful for an attacker<br />

to compromise <strong>the</strong> entire server.<br />

Command injection flaws of this kind have arisen in numerous off-<strong>the</strong>-shelf<br />

and custom-built <strong>web</strong> <strong>application</strong>s. They have been particularly prevalent within<br />

<strong>application</strong>s that provide an administrative interface to an enterprise server or<br />

to devices such as firewalls, printers, and routers. These <strong>application</strong>s often have<br />

particular requirements for operating system interaction that lead developers<br />

to use direct commands that incorporate user-supplied data.<br />

Example 1: Injecting Via Perl<br />

Consider <strong>the</strong> following Perl CGI code, which is part of a <strong>web</strong> <strong>application</strong> for<br />

server administration. This function allows administrators to specify a directory<br />

on <strong>the</strong> server and view a summary of its disk usage:<br />

#!/usr/bin/perl<br />

use strict;<br />

use CGI qw(:standard escapeHTML);<br />

print header, start_html(“”);<br />

print “”;<br />

my $command = “du -h --exclude php* /var/www/html”;<br />

$command= $command.param(“dir”);<br />

$command=`$command`;

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!