OWASP - User contributions [en]

Testing for Stack Traces (OTG-ERR-002)

2015-01-21T16:14:26Z

Asterix: /* Black Box testing */ Corrected typo - final ")" at the end of first bullet.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attacker. Attackers attempt to generate these stack traces by tampering with the input to the web application with malformed HTTP requests and other input data.

If the application responds with stack traces that are not managed it could reveal information useful to attackers. This information could then be used in further attacks. Providing debugging information as a result of operations that generate errors is considered a bad practice due to multiple reasons. For example, it may contain information on internal workings of the application such as relative paths of the point where the application is installed or how objects are referenced internally.

==How to Test==
=== Black Box testing ===

There are a variety of techniques that will cause exception messages to be sent in an HTTP response. Note that in most cases this will be an HTML page, but exceptions can be sent as part of SOAP or REST responses too.

Some tests to try include:
*invalid input (such as input that is not consistent with application logic).
*input that contains non alphanumeric characters or query syntax.
*empty inputs.
*inputs that are too long.
*access to internal pages without authentication.
*bypassing application flow.

All the above tests could lead to application errors that may contain stack traces. It is recommended to use a fuzzer in addition to any manual testing.

Some tools, such as [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]] and Burp proxy will automatically detect these exceptions in the response stream as you are doing other penetration and testing work.

=== Gray Box Testing ===

Search the code for the calls that cause an exception to be rendered to a String or output stream. For example, in Java this might be code in a JSP that looks like:

<pre><% e.printStackTrace( new PrintWriter( out ) ) %></pre>

In some cases, the stack trace will be specifically formatted into HTML, so be careful of accesses to stack trace elements.

Search the configuration to verify error handling configuration and the use of default error pages. For example, in Java this configuration can be found in web.xml.

==Tools==
[1] ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1

Talk:Testing for Error Code (OTG-ERR-001)

2015-01-21T16:12:02Z

Asterix: Proposition to move reference section to the end.

I propose to move Reference section to the end of the page (like it is done on many other pages).

Testing for XPath Injection (OTG-INPVAL-010)

2015-01-21T16:05:56Z

Asterix: Corrected link to reference [1] Previous link was outdated.

{{Template:OWASP Testing Guide v4}}

== 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, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document.<br>

== 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:

<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<account>guest</account>
</user>
</users>
</pre>

An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:

<pre>
string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())
</pre>

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:

<pre>
Username: ' or '1' = '1
Password: ' or '1' = '1
</pre>

Looks quite familiar, doesn't it? Using these parameters, the query becomes:

<pre>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
</pre>

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, introducing a syntax error in the query, and to check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
<br>

== References ==
'''Whitepapers'''<br>
* [1] Amit Klein: "Blind XPath Injection" - http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath
<br>

Talk:Testing for Heap Overflow

2015-01-21T15:59:02Z

Asterix: Proposition to change the order of sections "Heap Overflow" and "Stack Overflow"

If we look at this statement on the page: "Locating heap overflows requires closer examination in comparison to stack overflows" in should be logically concluded that we already discussed stack overflows, but in reality we are going to discuss it in the next section. I think, it is better to change the order of "Heap Overflow" and "Stack Overflow sections"