4.0

137
Web Application Penetration Testing
The original userid node has been commented out, leaving only
the injected one. The document now complies with its DTD rules.
Tools
• XML Injection Fuzz Strings (from wfuzz tool) -
https: /wfuzz.googlecode.com/svn/trunk/wordlist/Injections/
XML.txt
References
Whitepapers
• Alex Stamos: “Attacking Web Services” -
http: /www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt
• Gregory Steuck, “XXE (Xml eXternal Entity) attack”,
http: /www.securityfocus.com/archive/1/297714
Testing for SSI Injection (OTG-INPVAL-009)
Summary
Web servers usually give developers the ability to add small pieces
of dynamic code inside static HTML pages, without having to
deal with full-fledged server-side or client-side languages. This
feature is incarnated by the Server-Side Includes (SSI). In SSI injection
testing, we test if it is possible to inject into the application
data that will be interpreted by SSI mechanisms. A successful exploitation
of this vulnerability allows an attacker to inject code into
HTML pages or even perform remote code execution.
Server-Side Includes are directives that the web server parses
before serving the page to the user. They represent an alternative
to writing CGI programs or embedding code using server-side
scripting languages, when there’s only need to perform very simple
tasks. Common SSI implementations provide commands to
include external files, to set and print web server CGI environment
variables, and to execute external CGI scripts or system commands.
Putting an SSI directive into a static HTML document is as easy as
writing a piece of code like the following:
to print out the current time.
to include the output of a CGI script.
to include the content of a file or list files in a directory.
to include the output of a system command.
Then, if the web server’s SSI support is enabled, the server will
parse these directives. In the default configuration, usually, most
web servers don’t allow the use of the exec directive to execute
system commands.
As in every bad input validation situation, problems arise when the
user of a web application is allowed to provide data that makes
the application or the web server behave in an unforeseen manner.
With regard to SSI injection, the attacker could provide input
that, if inserted by the application (or maybe directly by the server)
into a dynamically generated page, would be parsed as one or
more SSI directives.
This is a vulnerability very similar to a classical scripting language
injection vulnerability. One mitigation is that the web server needs
to be configured to allow SSI. On the other hand, SSI injection vulnerabilities
are often simpler to exploit, since SSI directives are
easy to understand and, at the same time, quite powerful, e.g.,
they can output the content of files and execute system commands.
How to Test
Black Box testing
The first thing to do when testing in a Black Box fashion is finding
if the web server actually supports SSI directives. Often, the answer
is yes, as SSI support is quite common. To find out we just
need to discover which kind of web server is running on our target,
using classic information gathering techniques.
Whether we succeed or not in discovering this piece of information,
we could guess if SSI are supported just by looking at the
content of the target web site. If it contains .shtml files, then SSI
are probably supported, as this extension is used to identify pages
containing these directives. Unfortunately, the use of the shtml
extension is not mandatory, so not having found any shtml files
doesn’t necessarily mean that the target is not prone to SSI injection
attacks.
The next step consists of determining if an SSI injection attack is
actually possible and, if so, what are the input points that we can
use to inject our malicious code.
The testing activity required to do this is exactly the same used to
test for other code injection vulnerabilities. In particular, we need
to find every page where the user is allowed to submit some kind
of input, and verify whether the application is correctly validating
the submitted input. If sanitization is insufficient, we need to test
if we can provide data that is going to be displayed unmodified (for
example, in an error message or forum post). Besides common
user-supplied data, input vectors that should always be considered
are HTTP request headers and cookies content, since they
can be easily forged.
Once we have a list of potential injection points, we can check if
the input is correctly validated and then find out where the provided
input is stored. We need to make sure that we can inject
characters used in SSI directives:
< ! # = / . “ - > and [a-zA-Z0-9]
To test if validation is insufficient, we can input, for example, a
string like the following in an input form: