the-web-application-hackers-handbook

Chapter 10 n Attacking Back-End Components 363
Finding OS Command Injection Flaws
In your application mapping exercises (see Chapter 4), you should have identified
any instances where the web application appears to be interacting with
the underlying operating system by calling external processes or accessing the
filesystem. You should probe all these functions, looking for command injection
flaws. In fact, however, the application may issue operating system commands
containing absolutely any item of user-supplied data, including every URL and
body parameter and every cookie. To perform a thorough test of the application,
you therefore need to target all these items within every application function.
Different command interpreters handle shell metacharacters in different ways.
In principle, any type of application development platform or web server may
call out to any kind of shell interpreter, running either on its own operating system
or that of any other host. Therefore, you should not make any assumptions
about the application’s handling of metacharacters based on any knowledge of
the web server’s operating system.
Two broad types of metacharacters may be used to inject a separate command
into an existing preset command:
n The characters ;|& and newline may be used to batch multiple commands,
one after the other. In some cases, these characters may be doubled with
different effects. For example, in the Windows command interpreter,
using && causes the second command to run only if the first is successful.
Using || causes the second command to always run, regardless of the
success of the first.
n The backtick character (`) can be used to encapsulate a separate command
within a data item being processed by the original command. Placing an
injected command within backticks causes the shell interpreter to execute
the command and replace the encapsulated text with the results of this
command before continuing to execute the resulting command string.
In the previous examples, it was straightforward to verify that command injection
was possible and to retrieve the results of the injected command, because
those results were returned immediately within the application’s response.
In many cases, however, this may not be possible. You may be injecting into a
command that returns no results and which does not affect the application’s
subsequent processing in any identifiable way. Or the method you have used
to inject your chosen command may be such that its results are lost as multiple
commands are batched together.
In general, the most reliable way to detect whether command injection is
possible is to use time-delay inference in a similar way as was described for
exploiting blind SQL injection. If a potential vulnerability appears to exist, you
can then use other methods to confirm this and to retrieve the results of your
injected commands.