OWASP - User contributions [en]

Testing for XPath Injection (OTG-INPVAL-010)

2014-04-22T21:50:45Z

Irene Abezgauz: slight change to summary

{{Template:OWASP Testing Guide v4}}

== Brief 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.

== Short Description of the Issue ==
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. 

== Black Box testing and example ==
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.
 

== References ==
'''Whitepapers''' 
* [1] Amit Klein: "Blind XPath Injection" - http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath

Test Session Timeout (OTG-SESS-007)

2014-04-22T21:48:15Z

Irene Abezgauz: small additions and changes

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
In this phase, we check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
 
== Description of the Issue ==
All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.
The most appropriate timeout should be a right balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute logout time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes it's, in general, recommended). In any case, any application that does not enforce a timeout-based logout should be considered not secure, unless such behavior is required by a specific functional requirement. 
The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. 
Session timeout management and expiration must be enforced server-side. If some data, under the control of the client, are used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client. 
Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to logout from the application.
More specifically, as for the logout function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens.
If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult. 
The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., webmail, online bank account): if the user moves away from the computer, without explicitly logging out, and the session timeout is not implemented on the application, then an attacker could access to the same account even long time after, for instance, by simply pressing the “back” button of the browser.

== Black Box testing and example ==
 
The same approach that we have seen in the [[Testing for logout functionality (OWASP-SM-007)]] section can be applied when measuring the timeout logout.
 
The testing methodology is very similar. First, we have to check whether a timeout exists, for instance, by logging in and then killing some time reading some other Testing Guide chapter, waiting for the timeout logout to be triggered. As in the logout function, after the timeout has passed, all session tokens should be destroyed or be unusable.
 
Then, if the timeout is configured, we need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), we can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., login time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, we could try to modify the cookie (if it's not cryptographically protected) and see what happens to our session. For instance, we can set the cookie expiration date far in the future and see whether our session can be prolonged.
 
As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
 

== Gray Box testing and example ==
 
We need to check that:
* The logout function effectively destroys all session token, or at least renders them unusable,
* The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.
 
Note: the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
 

== References ==
'''OWASP Resources'''
* [[Session Management Cheat Sheet]]

Testing for Session puzzling (OTG-SESS-008)

2014-04-22T21:42:51Z

Irene Abezgauz: minor addition to description, minor edits

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions not limited to:
* Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
* Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
* Skip over qualifying phases in multiphase processes, even if the process includes all the commonly recommended code level restrictions.
* Manipulate server-side values in indirect methods that cannot be predicted or detected.
* Execute traditional attacks in locations that were previously unreachable, or even considered secure.

== Description of the Issue ==

This vulnerability occurs when an application uses the same session variable for more than one purpose.
An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.

For example an attacker could use session variable overloading to bypass authentication enforcement mechanisms
of applications that enforce authentication by validating the existence of session
variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context. For example - an
authentication bypass attack vector could be executed by accessing a publicly
accessible entry point (e.g. a password recovery page) that populates the session with
an identical session variable, based on fixed values or on user originating input.

== Black Box Testing and Examples ==

This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing, obviously, this procedure is difficult and requires some luck since every different sequence could lead to a different result.

===Examples===

A very simple example could be the password reset functionality that, in the entry point, could request to the user some identifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.

== Gray Box testing and example ==

The most effective way to detect these vulnerabilities is via a source code review.

==Prevention==

Session variables should only be used for a single consistent purpose.

==References==
'''Whitepapers''' 
* Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
* Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

Testing for Error Code (OTG-ERR-001)

2014-04-22T21:38:24Z

Irene Abezgauz: minor changes and additions

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Often, during a penetration test on web applications, we come up against many error codes generated from applications or web servers.
It's possible to cause these errors to be displayed by using a particular requests, either specially crafted with tools or created manually.
These codes are very useful to penetration testers during their activities, because they reveal a lot of information about databases, bugs, and other technological components directly linked with web applications.
Within this section we'll analyse the more common codes (error messages) and bring into focus the steps of vulnerability assessment.
The most important aspect for this activity is to focus one's attention on these errors, seeing them as a collection of information that will aid in the next steps of our analysis. A good collection can facilitate assessment efficiency by decreasing the overall time taken to perform the penetration test.

Attackers sometimes use search engines to locate errors that disclose information. Searches can be performed to find any erroneous sites as random victims, or it is possible to search for errors in a specific site using the search engine filtering tools as described in [https://www.owasp.org/index.php/Testing:_Search_engine_discovery/reconnaissance_(OWASP-IG-002) 4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001)]

== Description of the Issue ==

===Web Server Errors===

A common error that we can see during testing is the HTTP 404 Not Found.
Often this error code provides useful details about the underlying web server and associated components. For example:

<pre>
Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
</pre>

This error message can be generated by requesting a non-existent URL.
After the common message that shows a page not found, there is information about web server version, OS, modules and other products used.
This information can be very important from an OS and application type and version identification point of view.

Other HTTP response codes such as 400 Bad Request, 405 Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out and 505 HTTP Version Not Supported can be forced by an attacker. When receiving specially crafted requests, web servers may provide one of these error codes depending on their HTTP implementation.

Testing for disclosed information in the Web Server error codes is related testing for information disclosed in the HTTP headers as described in the section [https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)].

===Application Server Errors===

Application errors are returned by the application itself, rather than the web server. These could be error messages from framework code (ASP, JSP etc.) or they could be specific errors returned by the application code.
Detailed application errors typically provide information of server paths, installed libraries and application versions.

===Database Errors===

Database errors are those returned by the Database System when there is a problem with the query or the connection. Each Database system, such as MySQL, Oracle or MSSQL, has their own set of errors. Those errors can provide sensible information such as Database server IPs, tables, columns and login details.

In addition, there are many SQL Injection exploitation techniques that utilize detailed error messages from the database driver, for in depth information on this issue see [https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OWASP-DV-005%29 Testing for SQL Injection (OWASP-DV-005)] for more information.

Web server errors aren't the only useful output returned requiring security analysis. Consider the next example error message:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied
</pre>

What happened? We will explain step-by-step below.

In this example, the 80004005 is a generic IIS error code which indicates that it could not establish a connection to its associated database. In many cases, the error message will detail the type of the database. This will often indicate the underlying operating system by association. With this information, the penetration tester can plan an appropriate strategy for the security test.

By manipulating the variables that are passed to the database connect string, we can invoke more detailed errors.
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key 'DriverId'
</pre>

In this example, we can see a generic error in the same situation which reveals the type and version of the associated database system and a dependence on Windows operating system registry key values.

Now we will look at a practical example with a security test against a web application that loses its link to its database server and does not handle the exception in a controlled manner. This could be caused by a database name resolution issue, processing of unexpected variable values, or other network problems.

Consider the scenario where we have a database administration web portal, which can be used as a front end GUI to issue database queries, create tables, and modify database fields. During the POST of the logon credentials, the following error message is presented to the penetration tester. The message indicates the presence of a MySQL database server:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

If we see in the HTML code of the logon page the presence of a '''hidden field''' with a database IP, we can try to change this value in the URL with the address of database server under the penetration tester's control in an attempt to fool the application into thinking that the logon was successful.

Another example: knowing the database server that services a web application, we can take advantage of this information to carry out a SQL Injection for that kind of database or a persistent XSS test.

==Web Server Configuration==

===Error Handling in IIS and ASP .net===

ASP .net is a common framework from Microsoft used for developing web applications. IIS is one of the commonly used web servers. Errors occur in all applications, developers try to trap most errors but it is almost impossible to cover each and every exception (it is however possible to configure the web server to suppress detailed error messages from being returned to the user).

IIS uses a set of custom error pages generally found in c:\winnt\help\iishelp\common to display errors like '404 page not found' to the user. These default pages can be changed and custom errors can be configured for IIS server. When IIS receives a request for an aspx page, the request is passed on to the dot net framework.

There are various ways by which errors can be handled in dot net framework. Errors are handled at three places in ASP .net:

# Inside Web.config customErrors section
# Inside global.asax Application_Error Sub
# At the the aspx or associated codebehind page in the Page_Error sub

'''Handling errors using web.config'''
<pre>
<customErrors defaultRedirect="myerrorpagedefault.aspx" mode="On|Off|RemoteOnly">
<error statusCode="404" redirect="myerrorpagefor404.aspx"/>
<error statusCode="500" redirect="myerrorpagefor500.aspx"/>
</customErrors>
</pre>

mode="On" will turn on custom errors. mode=RemoteOnly will show custom errors to the remote web application users. A user accessing the server locally will be presented with the complete stack trace and custom errors will not be shown to him.

All the errors, except those explicitly specified, will cause a redirection to the resource specified by defaultRedirect, i.e., myerrorpagedefault.aspx.
A status code 404 will be handled by myerrorpagefor404.aspx.

'''Handling errors in Global.asax'''

When an error occurs, the Application_Error sub is called. A developer can write code for error handling/page redirection in this sub.

<pre>
Private Sub Application_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Handling errors in Page_Error sub'''

This is similar to application error.

<pre>
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Error hierarchy in ASP .net'''

Page_Error sub will be processed first, followed by global.asax Application_Error sub, and, finally, customErrors section in web.config file.

Information Gathering on web applications with server-side technology is quite difficult, but the information discovered can be useful for the correct execution of an attempted exploit (for example, SQL injection or Cross Site Scripting (XSS) attacks) and can reduce false positives.

'''How to test for ASP.net and IIS Error Handling'''

Fire up your browser and type a random page name

<pre>
http:\\www.mywebserver.com\anyrandomname.asp
</pre>

If the server returns

<pre>
The page cannot be found

Internet Information Services
</pre>

it means that IIS custom errors are not configured. Please note the .asp extension.

Also test for .net custom errors. Type a random page name with aspx extension in your browser

<pre>
http:\\www.mywebserver.com\anyrandomname.aspx
</pre>

If the server returns

<pre>
Server Error in '/' Application.
--------------------------------------------------------------------------------

The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
</pre>

custom errors for .net are not configured.

===Error Handling in Apache===

Apache is a common HTTP server for serving HTML and PHP web pages. By default, Apache shows the server version, products installed and OS system in the HTTP error responses.

Responses to the errors can be configured and customized globally, per site or per directory in the apache2.conf using the ErrorDocument directive [2]

<pre>
ErrorDocument 404 “Customized Not Found error message”
ErrorDocument 403 /myerrorpagefor403.html
ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
</pre>

Site administrators are able to manage their own errors using .htaccess file if the global directive AllowOverride is configured properly in apache2.conf [3]

The information shown by Apache in the HTTP errors can also be configured using the directives ServerTokens [4] and ServerSignature [5] at apache2.conf configuration file. “ServerSignature Off” (On by default) removes the server information from the error responses, while ServerTokens [ProductOnly|Major|Minor|Minimal|OS|Full] (Full by default) defines what information has to be shown in the error pages.

===Error Handling in Tomcat===

Tomcat is a HTTP server to host JSP and Java Servlet applications. By default, Tomcat shows the server version in the HTTP error responses.

Customization of the error responses can be configured in the configuration file web.xml.

<pre>
<error-page>
<error-code>404</error-code>
<location>/myerrorpagefor404.html</location>
</error-page>
</pre>

== Black Box Testing Examples ==
Below are some examples of testing for detailed error messages returned to the user. Each of the below examples has specific information about the operating system, application version, etc.

'''Test: 404 Not Found'''
<pre>
telnet <host target> 80
GET /<wrong page> HTTP/1.1
host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>404 Not Found</title>
...
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Network problems leading to the application being unable to access the database server
</pre>
'''Result:'''
<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) '
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

'''Test:'''
<pre>
Authentication failure due to missing credentials
</pre>
'''Result:'''

Firewall version used for authentication: 
<pre>
Error 407
FW-1 at <firewall>: Unauthorized to access the document.
• Authorization is needed for FW-1.
• The authentication required by FW-1 is: unknown.
• Reason for failure of last attempt: no user
</pre>

'''Test: 400 Bad Request'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 400 Bad Request
Date: Fri, 06 Dec 2013 23:57:53 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>400 Bad Request</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at 127.0.1.1 Port 80</address>
...
</pre>

'''Test: 405 Method Not Allowed'''
<pre>
telnet <host target> 80
PUT /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 405 Method Not Allowed
Date: Fri, 07 Dec 2013 00:48:57 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 315
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>405 Method Not Allowed</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 408 Request Time-out'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
- Wait X seconds – (Depending on the target server, 21 seconds for Apache by default)
</pre>
'''Result:'''
<pre>
HTTP/1.1 408 Request Time-out
Date: Fri, 07 Dec 2013 00:58:33 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 298
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>408 Request Time-out</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 501 Method Not Implemented'''
<pre>
telnet <host target> 80
RENAME /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 501 Method Not Implemented
Date: Fri, 08 Dec 2013 09:59:32 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 299
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>501 Method Not Implemented</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Enumeration of directories by using access denied error messages: 

http://<host>/<dir>
</pre>
'''Result:'''
<pre>
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
</pre>
<pre>
Forbidden
You don't have permission to access /<dir> on this server.
</pre>

== Tools ==
* [1] ErrorMint - http://sourceforge.net/projects/errormint/ 
* [2] 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
* [2] [[http://httpd.apache.org/docs/2.2/mod/core.html#errordocument ErrorDocument]] Apache ErrorDocument Directive
* [3] [[http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride AllowOverride]] Apache AllowOverride Directive
* [4] [[http://httpd.apache.org/docs/2.2/mod/core.html#servertokens ServerTokens]] Apache ServerTokens Directive
* [5] [[http://httpd.apache.org/docs/2.2/mod/core.html#serversignature ServerSignature]] Apache ServerSignature Directive

[[Category:OWASP .NET Project]]

Testing for Stack Traces (OTG-ERR-002)

2014-04-22T21:26:18Z

Irene Abezgauz: minor changes and additions

{{Template:OWASP Testing Guide v4}}

== Brief 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.

== Description of the Issue ==

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.

== Black Box testing and example ==

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 things to attempt: 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 etc.), access to internal pages without authentication, bypassing application flow etc. all these 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 and example ==

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.

== References ==

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

Testing for cookies attributes (OTG-SESS-002)

2014-04-22T21:15:06Z

Irene Abezgauz: small additions

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Cookies are often a key attack vector for malicious users (typically targeting other users) and, as such, the application should always take due diligence to protect cookies. In this section, we will look at how an application can take the necessary precautions when assigning cookies, and how to test that these attributes have been correctly configured.

== Description of the Issue ==
The importance of secure use of Cookies cannot be understated, especially within dynamic web applications, which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token or as a temporary data container. Thus, if an attacker were by some means able to acquire a session token (for example, by exploiting a cross site scripting vulnerability or by sniffing an unencrypted session), then he/she could use this cookie to hijack a valid session. Additionally, cookies are set to maintain state across multiple requests. Since HTTP is stateless, the server cannot determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although other methods are also possible. As you can imagine, there are many different types of applications that need to keep track of session state across multiple requests. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart, this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the application's HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie, the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies, they are typically encoded or encrypted in an attempt to protect the information they contain. Often, multiple cookies will be set (separated by a semicolon) upon subsequent requests. For example, in the case of an online store, a new cookie could be set as you add multiple items to your shopping cart. Additionally, you will typically have a cookie for authentication (session token as indicated above) once you log in, and multiple other cookies used to identify the items you wish to purchase and their auxiliary information (i.e., price and quantity) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance, let's take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if it is a sub-domain, then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute cannot be a top level domain (such as .gov or .com) to prevent servers from setting arbitrary cookies for another domain. If the domain attribute is not set, then the hostname of the server which generated the cookie is used as the default value of the domain.
For example, if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction, then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com and its subdomains, such as hacker.app.mydomain.com, and even bank.mydomain.com.
If there was a vulnerable server on a subdomain (for example, otherapp.mydomain.com) and the domain attribute has been set too loosely (for example, mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match, then the cookie will be sent in the request.
Just as with the domain attribute, if the path attribute is set too loosely, then it could leave the application vulnerable to attacks by other applications on the same server. For example, if the path attribute was set to the web server root "/", then the application cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded, the browser will delete the cookie. Alternatively, if this attribute is not set, then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for cookie attribute vulnerabilities:''' 

By using an intercepting proxy or traffic intercepting browser plug-in, trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel. For example, after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not, then the browser would agree to pass it via an unencrypted channel such as using HTTP, and this could lead to an attacker leading users into submitting their cookie over an insecure channel.

*HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aids in securing the cookie from being accessed by a client side script, it does not eliminate cross site scripting risks but does eliminate some exploitation vectors. Check to see if the ";HttpOnly" tag has been set.

*Domain Attribute - Verify that the domain has not been set too loosely. As noted above, it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com, then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.

*Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used, the browser will send the cookie to any path that matches "myapp" such as "myapp-exploited".

*Expires Attribute - Verify that, if this attribute is set to a time in the future, that the cookie does not contain any sensitive information. For example, if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008, then you want to inspect the cookie. If the cookie is a session token that is stored on the user's hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

== References ==
'''Whitepapers''' 

*RFC 2965 - HTTP State Management Mechanism - http://tools.ietf.org/html/rfc2965

*RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 - http://tools.ietf.org/html/rfc2616

*The important "expires" attribute of Set-Cookie http://seckb.yehg.net/2012/02/important-expires-attribute-of-set.html

* HttpOnly Session ID in URL and Page Body http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

'''Tools''' 

'''Intercepting Proxy:'''

* '''[[:OWASP Zed Attack Proxy Project]]'''

'''Browser Plug-in:'''

* "TamperIE" for Internet Explorer -
http://www.bayden.com/TamperIE/

*Adam Judson: "Tamper Data" for Firefox -
https://addons.mozilla.org/en-US/firefox/addon/966

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2014-04-22T21:03:11Z

Irene Abezgauz: minor corrections and changes, added a tools section

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- site design and layout 
- data manipulation 
- configuration changes 

In many instances, such interfaces do not have sufficient controls to protect them from unauthorized access. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation, and are described elsewhere in this guide(for example [https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_%28OWASP-AZ-002%29 Testing for Bypassing Authorization Schema (OWASP-AZ-002)] and [https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_%28OWASP-AZ-004%29 Testing for Insecure Direct Object References (OWASP-AZ-004)] in greater detail.

* Directory and file enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting: ''/admin or /administrator etc..'' or in some scenarios can be revealed within seconds using [http://www.exploit-db.com/google-dorks Google dorks].
* There are many tools available to perform brute forcing of server contents, see the tools section below for more information.

A tester may have to also identify the filename of the administration page. Forcibly browsing to the identified page may provide access to the interface.

* Comments and links in source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing server and application documentation - If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Publicly available information – many applications such as wordpress have default administrative interfaces

* Alternative server port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no">

or in a cookie:

Cookie: session_cookie; useradmin=0

Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
A more detailed examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Default Password list: http://www.cirt.net/passwords

== Tools ==
* [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project Dirbuster] This currently inactive OWASP project is still a great tool for brute forcing directories and files on the server.
* [https://www.thc.org/thc-hydra/ THC-HYDRA] is a tool that allows brute-forcing of many interfaces, including form-based HTTP authentication.

A brute forcer is much better when it uses a good dictionary, for example the [https://www.netsparker.com/blog/web-security/svn-digger-better-lists-for-forced-browsing/ netsparker] dictionary.

User:Irene Abezgauz

2014-04-22T20:49:05Z

Irene Abezgauz:

I've been in application security for over a decade, as penetration tester, consultant, researcher, social engineering enthusiast and breaker of things in general.
 Currently I'm VP Product Management at [http://www.quotium.com Quotium] - creating rather than breaking for a change!

I also lead the Seeker Research Center, where we are constantly on the look for new techniques and exploitation vectors, as well as causing vendors to scratch their heads occasionally when we identify a new vulnerability in one of their products.

Current OWASP involvement:
OWASP Testing Guide v3
OWASP Testing Guide v4
Speaker in OWASP Conferences

Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)

2014-04-22T20:35:39Z

Irene Abezgauz: some corrections, some clarifications

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities, as explained in the broader article [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)] [1] and in other OWASP documentation [2], [3], [4], [5]. As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. Some examples for sensitive data are:
* Information used in Authentication (e.g. Credentials, PINs, Session identifiers, Tokens, Cookies…)
* Information protected by Laws, Regulations or specific organizational Policy (e.g. Credit Cards, Customers data)

== Description of the Issue ==
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is considered a security risk. Some examples are Basic authentication which sends authentication credentials in plain-text over HTTP, form based authentication credentials sent via HTTP, or plain-text transmission of any other information considered sensitive due to regulations, laws, organizational policy or application business logic.

== Black Box testing and examples ==
Various types of information which must be protected, could be transmitted by the application in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS, or whether weak cyphers are used. See more information about insecure transmission of credentials [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure] [3] or insufficient transport layer protection in general [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection Top 10 2010-A9-Insufficient Transport Layer Protection] [2].

=== Example 1: Basic Authentication over HTTP ===
A typical example is the usage of Basic Authentication over HTTP. When using Basic Authentication, user credentials are encoded rather than encrypted, and are sent as HTTP headers. In the example below we use curl [5] to test for this issue. Note how the application uses Basic authentication, and HTTP rather than HTTPS

<pre>
$ curl -kis http://example.com/restricted/
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT
WWW-Authenticate: Basic realm="Restricted Area"
Accept-Ranges: bytes Vary:
Accept-Encoding Content-Length: 162
Content-Type: text/html

<html><head><title>401 Authorization Required</title></head>
<body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login credentials! </body></html>
</pre>

=== Example 2: Form-Based Authentication Performed over HTTP ===
Another typical example is authentication forms which transmit user authentication credentials over HTTP. In the example below we see HTTP being used in the "action" attribute of the form. It is also possible to see this issue by examining the HTTP traffic with an interception proxy.

<pre>
<form action="http://example.com/login">
<label for="username">User:</label> <input type="text" id="username" name="username" value=""/> 
<label for="password">Password:</label> <input type="password" id="password" name="password" value=""/>
<input type="submit" value="Login"/>
</form>
</pre>

=== Example 3: Cookie Containing Session ID Sent over HTTP ===
The Session ID Cookie must be transmitted over protected channels. If the cookie does not have the secure flag set [6] it is permitted for the application to transmit it unencrypted.. Note below the setting of the cookie is done without the Secure flag, and the entire login process is performed in HTTP and not HTTPS.

<pre>
https://secure.example.com/login

POST /login HTTP/1.1
Host: secure.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://secure.example.com/
Content-Type: application/x-www-form-urlencoded
Content-Length: 188

HTTP/1.1 302 Found
Date: Tue, 03 Dec 2013 21:18:55 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly
Location: private/
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html

----------------------------------------------------------
http://example.com/private

GET /private HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://secure.example.com/login
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
Connection: keep-alive

HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Expires: 0
Content-Type: text/html;charset=UTF-8
Content-Length: 730
Date: Tue, 25 Dec 2013 00:00:00 GMT
----------------------------------------------------------
</pre>

==References==
'''OWASP Resources'''
* [1] [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002 OWASP Testing Guide - Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-CRYPST-002)]
* [2] [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection OWASP TOP 10 2010 - Insufficient Transport Layer Protection]
* [3] [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure OWASP TOP 10 2013 - Sensitive Data Exposure]
* [4] [https://code.google.com/p/owasp-asvs/wiki/Verification_V10 OWASP ASVS v1.1 - V10 Communication Security Verification Requirements]
* [6] [https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002) OWASP Testing Guide - Testing for Cookies attributes (OTG-SESS-002)]
'''Tools'''
* [5] [http://curl.haxx.se/ curl] can be used to check manually for pages

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2013-12-16T21:04:44Z

Irene Abezgauz:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 
== Description of the Issue ==
 
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 
== Black Box testing and example ==
To test for this vulnerability the tester needs to first map out all locations in the application where user input is used to reference objects directly. For example – locations where user input is used to access a database row, a file, application pages and more.
At the next step the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functionalities. For example two users each having access to different objects (such as purchase information, private messages, etc), and if relevant users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access with one user objects that belong to the other.

Below are several typical scenarios for this vulnerability and the methods to test for each: 

* The value of a parameter is used directly to retrieve a database record:

sample request: http://foo.bar/somepage?invoice=12345

In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization. 
* The value of a parameter is used directly to perform an operation in the system:

sample request: [http://foo.bar/changepassword?user=someuser http://foo.bar/changepassword?user=someuser]

in this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user we are changing the password, and in the next step the user will provide a new password (without asking for the current one). The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user. 

* The value of a parameter is used directly to retrieve a file system resource:

sample request: [http://foo.bar/showImage?img=img00011 http://foo.bar/showImage?img=img00011]

In this case, the value of the ''file'' parameter is used to tell the application which file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users. To test for this case, the tester should obtain a reference the user is supposed to not be able to access and attempt placing it as the value of ''file''.
Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [https://www.owasp.org/index.php/Testing_for_Path_Traversal_%28OWASP-AZ-001%29 Testing for Path Traversal]) 

* The value of a parameter is used directly to access application functionality:

sample request: [http://foo.bar/accessPage?menuitem=12 http://foo.bar/accessPage?menuitem=12]

In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1,2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References Top 10 2013-A4-Insecure Direct Object References]

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2013-12-16T21:03:21Z

Irene Abezgauz:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 
== Description of the Issue ==
 
Applications with Insecure Direct Object References allow attackers to bypass authorization and access application resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 
== Black Box testing and example ==
To test for this vulnerability the tester needs to first map out all locations in the application where user input is used to reference objects directly. For example – locations where user input is used to access a database row, a file, application pages and more.
At the next step the tester should modify the value of the parameter used to reference objects directly and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functionalities. For example two users each having access to different objects (such as purchase information, private messages, etc), and if relevant users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access with one user objects that belong to the other.

Below are several typical scenarios for this vulnerability and the methods to test for each: 

* The value of a parameter is used directly to retrieve a database record:

sample request: http://foo.bar/somepage?invoice=12345

In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization. 
* The value of a parameter is used directly to perform an operation in the system:

sample request: [http://foo.bar/changepassword?user=someuser http://foo.bar/changepassword?user=someuser]

in this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user we are changing the password, and in the next step the user will provide a new password (without asking for the current one). The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user. 

* The value of a parameter is used directly to retrieve a file system resource:

sample request: [http://foo.bar/showImage?img=img00011 http://foo.bar/showImage?img=img00011]

In this case, the value of the ''file'' parameter is used to tell the application which file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users. To test for this case, the tester should obtain a reference the user is supposed to not be able to access and attempt placing it as the value of ''file''.
Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [https://www.owasp.org/index.php/Testing_for_Path_Traversal_%28OWASP-AZ-001%29 Testing for Path Traversal]) 

* The value of a parameter is used directly to access application functionality:

sample request: [http://foo.bar/accessPage?menuitem=12 http://foo.bar/accessPage?menuitem=12]

In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1,2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References Top 10 2013-A4-Insecure Direct Object References]

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2013-12-16T21:00:39Z

Irene Abezgauz:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 
== Description of the Issue ==
 
Applications with Insecure Direct Object References allow attackers to bypass authorization and access application resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 
== Black Box testing and example ==
To test for this vulnerability the tester needs to first map out all locations in the application where user input is used to reference objects directly. For example – locations where user input is used to access a database row, a file, application pages and more.
At the next step the tester should modify the value of the parameter used to reference objects directly and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functionalities. For example two users each having access to different objects (such as purchase information, private messages, etc), and if relevant users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access with one user objects that belong to the other.

'''Below are several typical scenarios for this vulnerability and the methods to test for each: ''' 

1. The value of a parameter is used directly to retrieve a database record:

sample request: http://foo.bar/somepage?invoice=12345

In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization. 
2. The value of a parameter is used directly to perform an operation in the system:

sample request: [http://foo.bar/changepassword?user=someuser http://foo.bar/changepassword?user=someuser]

in this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user we are changing the password, and in the next step the user will provide a new password (without asking for the current one). The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user. 

3. The value of a parameter is used directly to retrieve a file system resource:

sample request: [http://foo.bar/showImage?img=img00011 http://foo.bar/showImage?img=img00011]

In this case, the value of the ''file'' parameter is used to tell the application which file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users. To test for this case, the tester should obtain a reference the user is supposed to not be able to access and attempt placing it as the value of ''file''.
Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [https://www.owasp.org/index.php/Testing_for_Path_Traversal_%28OWASP-AZ-001%29 Testing for Path Traversal]) 

4. The value of a parameter is used directly to access application functionality:

sample request: [http://foo.bar/accessPage?menuitem=12 http://foo.bar/accessPage?menuitem=12]

In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1,2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References Top 10 2013-A4-Insecure Direct Object References]

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2013-12-16T20:59:55Z

Irene Abezgauz:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 
== Description of the Issue ==
 
Applications with Insecure Direct Object References allow attackers to bypass authorization and access application resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 
== Black Box testing and example ==
To test for this vulnerability the tester needs to first map out all locations in the application where user input is used to reference objects directly. For example – locations where user input is used to access a database row, a file, application pages and more.
At the next step the tester should modify the value of the parameter used to reference objects directly and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functionalities. For example two users each having access to different objects (such as purchase information, private messages, etc), and if relevant users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access with one user objects that belong to the other.

'''Below are several typical scenarios for this vulnerability and the methods to test for each: ''' 

1. The value of a parameter is used directly to retrieve a database record:

sample request: http://foo.bar/somepage?invoice=12345

In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization. 
2. The value of a parameter is used directly to perform an operation in the system:

sample request: [http://foo.bar/changepassword?user=someuser http://foo.bar/changepassword?user=someuser]

in this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user we are changing the password, and in the next step the user will provide a new password (without asking for the current one). The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user. 

3. The value of a parameter is used directly to retrieve a file system resource:

sample request: [http://foo.bar/showImage?img=img00011 http://foo.bar/showImage?img=img00011]

In this case, the value of the ''file'' parameter is used to tell the application which file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users. To test for this case, the tester should obtain a reference the user is supposed to not be able to access and attempt placing it as the value of ''file''.
Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [https://www.owasp.org/index.php/Testing_for_Path_Traversal_%28OWASP-AZ-001%29 Testing for Path Traversal]) 

4. The value of a parameter is used directly to access application functionality:

sample request: [http://foo.bar/accessPage?menuitem=12 http://foo.bar/accessPage?menuitem=12]

In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1,2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References Top 10 2013-A4-Insecure Direct Object References]

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2013-12-16T20:51:04Z

Irene Abezgauz:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 
== Description of the Issue ==
 
Applications with Insecure Direct Object References allow attackers to bypass authorization and access application resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 
== Black Box testing and example ==
To test for this vulnerability the tester needs to first map out all locations in the application where user input is used to reference objects directly. For example – locations where user input is used to access a database row, a file, application pages and more.
At the next step the tester should modify the value of the parameter used to reference objects directly and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functionalities. For example two users each having access to different objects (such as purchase information, private messages, etc), and if relevant users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access with one user objects that belong to the other.

'''Below are several typical scenarios for this vulnerability and the methods to test for each: ''' 
1. The value of a parameter is used directly to retrieve a database record:

sample request: http://foo.bar/somepage?invoice=12345

In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization. 
2. The value of a parameter is used directly to perform an operation in the system:

sample request: http://foo.bar/changepassword?user=someuser

in this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user we are changing the password, and in the next step the user will provide a new password (without asking for the current one). The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user. 
3. The value of a parameter is used directly to retrieve a file system resource:

sample request: http://foo.bar/showImage?file=image00011.jpg

In this case, the value of the ''file'' parameter is used to tell the application which file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users. To test for this case, the tester should obtain a reference the user is supposed to not be able to access and attempt placing it as the value of ''file''.
[Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [https://www.owasp.org/index.php/Testing_for_Path_Traversal_%28OWASP-AZ-001%29 Testing for Path Traversal]) 
4. The value of a parameter is used directly to access application functionality:

sample request: http://foo.bar/accessPage?menuitem=12

In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1,2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References]

User:Irene Abezgauz

2012-09-14T12:35:28Z

Irene Abezgauz:

I'm '''Irene Abezgauz'''. I've been living and breathing Application Security for nearly a decade now - as an Application Security Consultant, Jane-of-all-trades Penetration Tester (specializing in Proprietary Protocols and Wreaking Havoc in general), and currently as Product Manager - making rather than breaking for a change!

I am the Product Manager of [http://www.seekersec.com Seeker]. I also lead the '''Seeker Research Center''', where we are constantly on the look for new techniques and exploitation vectors, as well as causing vendors to scratch their heads occasionally when we identify a new vulnerability in one of their products.

Current OWASP involvement:
OWASP Testing Guide v4
Speaker in OWASP Conferences

User:Irene Abezgauz

2012-09-14T12:34:01Z

Irene Abezgauz:

I'm '''Irene Abezgauz'''. I've been living and breathing Application Security for nearly a decade now - as an Application Security Consultant, Jane-of-all-trades Penetration Tester (specializing in Proprietary Protocols and Wreaking Havoc in general), and currently as Product Manager - making rather than breaking for a change!

I am the Product Manager of [http://www.seekersec.com Seeker]. I also lead the '''Seeker Research Center''', where we are constantly on the look for new techniques and exploitation vectors, as well as causing vendors to scratch their heads occasionally when we identify a new vulnerability in one of their products.

Current OWASP involvement:
o OWASP Testing Guide v4
o Speaker in OWASP Conferences

OWASP Testing Guide v4 Table of Contents

2012-09-14T08:44:24Z

Irene Abezgauz:

__NOTOC__

'''This is DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 31st August 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following are the main improvements we have to realize: 

(1) - Add new testing techniques and OWASP Top10 update: 
- Testing for HTTP Verb tampering 
- Testing for HTTP Parameter Pollutions 
- Testing for URL Redirection 
- Testing for Insecure Direct Object References 
- Testing for Insecure Cryptographic Storage 
- Testing for Failure to Restrict URL Access 
- Testing for Insufficient Transport Layer Protection 
- Testing for Unvalidated Redirects and Forwards. 
 
(2) - Review and improve all the sections in v3, 
 
(3) - Create a more readable guide, eliminating some sections that are not
really useful, Rationalize some sections as Session Management Testing.

(4) Pavol says: - add new opensource testing tools that appeared during last 3 years
(and are missing in the OWASP Testing Guide v3)

- add few useful and life-scenarios of possible
vulnerabilities in Bussiness Logic Testing (many testers have no idea what
vulnerabilities in Business Logic exactly mean)

- "Brute force testing" of "session ID" is missing in "Session Management
Testing", describe other tools for Session ID entropy analysis
(e.g. Stompy)

- in "Data Validation Testing" describe some basic obfuscation methods for
malicious code injection including the statements how it is possible to
detect it (web application obfuscation is quite succesfull in bypassing
many data validation controls)

- split the phase Logout and Browser Cache Management" into two sections
 
The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by OWASP Chair]]==
[To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

Infrastructure Configuration management weakness 
Application Configuration management weakness 
File extensions handling 
Old, backup and unreferenced files 
Access to Admin interfaces 
Bad HTTP Methods enabled, [new] 
Informative Error Messages 
Database credentials/connection strings available 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

Credentials transport over an unencrypted channel [Robert Winkel] 
User enumeration (also Guessable user account) [Robert Winkel] 
Default passwords [Robert Winkel] 
Weak lock out mechanism [New! - Robert Winkel] 
Account lockout DoS [New! - Robert Winkel] 
Bypassing authentication schema 
Vulnerable remember password [Robert Winkel] 
Browser cache weakness [New!] 
Weak password policy [New! - Robert Winkel] 
Weak username policy [New! - Robert Winkel] 
Weak security question/answer [New! - Robert Winkel] 
Failure to restrict access to authenticated resource [New!] 
Weak password change function [New! - Robert Winkel] 
Testing for CAPTCHA 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

Bypassing Session Management Schema 
Weak Session Token 
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity 
Exposed sensitive session variables 
CSRF 
Session passed over http [New!] 
Session token within URL [New!] 
Session Fixation 
Session token not removed on server after logout [New!] 
Persistent session token [New!] 
Session token not restrcited properly (such as domain or path not set properly) [New!] 
Logout function not properly implemented 

[[Testing for Authorization|'''4.6 Authorization Testing''']]

Bypassing authorization schema 
Directory traversal/file include [Juan Galiana] 
Privilege Escalation [Irene Abezgauz] 
Insecure Direct Object References [Irene Abezgauz] 
Failure to Restrict access to authorized resource [New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

Reflected XSS 
Stored XSS 
HTTP Verb Tampering [Brad Causey] 
HTTP Parameter pollution [Brad Causey] 
Unvalidated Redirects and Forwards [Brad Causey] 
SQL Injection [Brad Causey] 
LDAP Injection 
ORM Injection 
XML Injection 
SSI Injection 
XPath Injection 
SOAP Injection 
IMAP/SMTP Injection 
Code Injection 
OS Commanding [Juan Galiana] 
Buffer overflow 
Incubated vulnerability 
HTTP Splitting/Smuggling [Juan Galiana] 

[[Testing for Data Encryption (New!)]]

Application did not use encryption 
Weak SSL/TSL Ciphers, Insufficient 
Transport Layer Protection 
Cacheable HTTPS Response 
Cache directives insecure 
Insecure Cryptographic Storage [mainly CR Guide] 
Sensitive information sent via unencrypted
channels 

[[ XML Interpreter? (New!)]]

Weak XML Structure
XML content-level
WS HTTP GET parameters/REST
WS Naughty SOAP attachments
WS Replay Testing

[[ Client Side Testing (New!) ]]

DOM XSS 
HTML5 [Juan Galiana] 
Cross Site Flashing 
ClickHijacking 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> contributor here]
* Books [To review--> contributor here]
* Useful Websites [To review--> contributor here]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]