1BO4r2U

135 136
Web Application Penetration Testing
Web Application Penetration Testing
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:
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.
[2] Where user input, cookie content and HTTP headers are handled.
The complete list of input vectors is then quickly determined.
[3] How the input is handled, what kind of filtering is performed, what
characters the application is not letting through, and how many types
of encoding are taken into account.
Performing these steps is mostly a matter of using grep to find the
right keywords inside the source code (SSI directives, CGI environment
variables, variables assignment involving user input, filtering functions
and so on).
unlike SQL, no ACLs are enforced, as our query can access every part of
the XML document.
How to Test
The XPath attack pattern was first published by Amit Klein [1] and is
very similar to the usual SQL Injection.In order to get a first grasp of
the problem, let’s imagine a login page that manages the authentication
to an application in which the user must enter his/her username
and password.Let’s assume that our database is represented by the
following XML file:
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,
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:
This is similar to testing for XSS vulnerabilities using
alert(“XSS”)
If the application is vulnerable, the directive is injected and it would be
interpreted by the server the next time the page is served, thus including
the content of the Unix standard password file.
The injection can be performed also in HTTP headers, if the web application
is going to use that data to build a dynamically generated page:
GET / HTTP/1.0
Referer:
User-Agent:
Gray Box testing
If we have access to the application source code, we can quite
easily find out:
[1] If SSI directives are used. If they are, then the web server is
going to have SSI support enabled, making SSI injection at least a
potential issue to investigate.
Tools
• Web Proxy Burp Suite - http:/portswigger.net
• Paros - http:/www.parosproxy.org/index.shtml
• WebScarab
• String searcher: grep - http:/www.gnu.org/software/grep
References
Whitepapers
• Apache Tutorial: “Introduction to Server Side Includes”
- http:/httpd.apache.org/docs/1.3/howto/ssi.html
• Apache: “Module mod_include” - http:/httpd.apache.org/
docs/1.3/mod/mod_include.html
• Apache: “Security Tips for Server Configuration” - http:/httpd.
apache.org/docs/1.3/misc/security_tips.html#ssi
• Header Based Exploitation - http:/www.cgisecurity.net/papers/
header-based-exploitation.txt
• SSI Injection instead of JavaScript Malware - http:/
jeremiahgrossman.blogspot.com/2006/08/ssi-injection-insteadof-javascript.html
• IIS: “Notes on Server-Side Includes (SSI) syntax” - http:/blogs.
iis.net/robert_mcmurray/archive/2010/12/28/iis-notes-on-serverside-includes-ssi-syntax-kb-203064-revisited.aspx
Testing for XPath Injection (OTG-INPVAL-010)
Summary
XPath is a language that has been designed and developed primarily
to address parts of an XML document. In XPath injection testing, we
test if it is possible to inject XPath syntax into a request interpreted by
the application, allowing an attacker to execute user-controlled XPath
queries.When successfully exploited, this vulnerability may allow an
attacker to bypass authentication mechanisms or access information
without proper authorization.
Web applications heavily use databases to store and access the
data they need for their operations.Historically, relational databases
have been by far the most common technology for data storage,
but, in the last years, we are witnessing an increasing popularity
for databases that organize data using the XML language.
Just like relational databases are accessed via SQL language, XML databases
use XPath as their standard query language.
Since, from a conceptual point of view, XPath is very similar to SQL in
its purpose and applications, an interesting result is that XPath injection
attacks follow the same logic as SQL Injection attacks. In some
aspects, XPath is even more powerful than standard SQL, as its whole
power is already present in its specifications, whereas a large number
of the techniques that can be used in a SQL Injection attack depend
on the characteristics of the SQL dialect used by the target database.
This means that XPath injection attacks can be much more adaptable
and ubiquitous.Another advantage of an XPath injection attack is that,
gandalf
!c3
admin
Stefan0
w1s3c
guest
tony
Un6R34kb!e
guest
An XPath query that returns the account whose username is “gandalf”
and the password is “!c3” would be the following:
string(/user[username/text()=’gandalf’ and password/text()=’!c3’]/account/text())
If the application does not properly filter user input, the tester will
be able to inject XPath code and interfere with the query result.
For instance, the tester could input the following values:
Username: ‘ or ‘1’ = ‘1
Password: ‘ or ‘1’ = ‘1
Looks quite familiar, doesn’t it? Using these parameters, the query
becomes:
string(/user[username/text()=’’ or ‘1’ = ‘1’ and password/
text()=’’ or ‘1’ = ‘1’]/account/text())
As in a common SQL Injection attack, we have created a query that always
evaluates to true, which means that the application will authenticate
the user even if a username or a password have not been provided.
And as in a common SQL Injection attack, with XPath injection, the
first step is to insert a single quote (‘) in the field to be tested, intro-