OWASP - User contributions [en]

Testing Guide Frontispiece

2008-10-07T09:57:39Z

Gian: /* v3 Authors */

{{Template:OWASP Testing Guide v3}}

==Welcome to the OWASP Testing Guide 3.0==
“Open and collaborative knowledge: that’s the OWASP way.” 
-- [[User:Mmeucci|Matteo Meucci]] 

OWASP thanks the many authors, reviewers, and editors for their hard work in bringing this guide to where it is today. If you have any comments or suggestions on the Testing Guide, please e-mail the Testing Guide mail list:

http://lists.owasp.org/mailman/listinfo/owasp-testing

Or drop a mail to the project leader: [mailto:matteo.meucci@gmail.com Matteo Meucci]

==Version 3.0==

The OWASP Testing Guide Version 3 wants to improve version 2 and create new sections and controls. This new version has added: 
• Configuration Management and Authorization Testing sections and Encoded Injection Appendix; 
• 36 new articles (1 taken from the BSP); 
Version 3 improved 9 articles, for a total of 10 Testing categories and 66 controls.

==Copyright and License==

Copyright (c) 2008 The OWASP Foundation.

This document is released under the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons 2.5 License]. Please read and understand the license and copyright conditions.

==Revision History ==

The Testing Guide v3 comes in September 2008. The Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to Eoin Keary in 2005 and transformed into a wiki. Matteo Meucci has decided to take on the Testing guide and is now the lead of the OWASP Testing Guide Project.

; 15th September, 2008
: "OWASP Testing Guide", Version 3.0

; December 25, 2006
: "OWASP Testing Guide", Version 2.0

; July 14, 2004
: "OWASP Web Application Penetration Checklist", Version 1.1

; December 2004
: "The OWASP Testing Guide", Version 1.0

== Editors ==
'''Matteo Meucci''': OWASP Testing Guide Lead from 2007. 

'''Eoin Keary''': OWASP Testing Guide 2005-2007 Lead. 

'''Daniel Cuthbert''': OWASP Testing Guide 2003-2005 Lead.

== v3 Authors ==

{| border="0"
| valign="top" |
* Anurag Agarwwal
* Daniele Bellucci
* Arian Coronel
* Stefano Di Paola
| valign="top" |
* Giorgio Fedon
* Adam Goodman
* Christian Heinrich
* Kevin Horvath
| valign="top" |
* Gianrico Ingrosso
* Roberto Suggi Liverani
* Kuza55
* Pavol Luptak
| valign="top" |
* Ferruh Mavituna
* Marco Mella
* Matteo Meucci
* Marco Morana
| valign="top" |
* Antonio Parata
* Cecil Su
* Harish Skanda Sureddy
* Mark Roxberry
| valign="top" |
* Andrew Van der Stock
|}

== v3 Reviewers ==

{| border="0"
| valign="top" |
* Marco Cova
* Kevin Fuller
| valign="top" |
* Matteo Meucci
* Nam Nguyen
|}

== v2 Authors ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Mauro Bregolin
* Tom Brennan
* Gary Burns
* Luca Carettoni
* Dan Cornell
* Mark Curphey
* Daniel Cuthbert
* Sebastien Deleersnyder
* Stephen DeVries
* Stefano Di Paola
| valign="top" |
* David Endler
* Giorgio Fedon
* Javier Fernández-Sanguino
* Glyn Geoghegan
* Stan Guzik
* Madhura Halasgikar
* Eoin Keary
* David Litchfield
* Andrea Lombardini
* Ralph M. Los
* Claudio Merloni
| valign="top" |
* Matteo Meucci
* Marco Morana
* Laura Nunez
* Gunter Ollmann
* Antonio Parata
* Yiannis Pavlosoglou
* Carlo Pelliccioni
* Harinath Pudipeddi
* Alberto Revelli
* Mark Roxberry
* Tom Ryan
| valign="top" |
* Anush Shetty
* Larry Shields
* Dafydd Studdard
* Andrew van der Stock
* Ariel Waissbein
* Jeff Williams
* Tushar Vartak
|}

== v2 Reviewers ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Marco Belotti
| valign="top" |
* Mauro Bregolin
* Marco Cova
| valign="top" |
* Daniel Cuthbert
* Paul Davies
| valign="top" |
* Stefano Di Paola
* Matteo G.P. Flora
| valign="top" |
* Simona Forti
* Darrell Groundy
| valign="top" |
* Eoin Keary
* James Kist
| valign="top" |
* Katie McDowell
* Marco Mella
| valign="top" |
* Matteo Meucci
* Syed Mohamed A.
| valign="top" |
* Antonio Parata
* Alberto Revelli
| valign="top" |
* Mark Roxberry
* Dave Wichers
|}

==Trademarks==

* Java, Java Web Server, and JSP are registered trademarks of Sun Microsystems, Inc.
* Merriam-Webster is a trademark of Merriam-Webster, Inc.
* Microsoft is a registered trademark of Microsoft Corporation.
* Octave is a service mark of Carnegie Mellon University.
* VeriSign and Thawte are registered trademarks of VeriSign, Inc.
* Visa is a registered trademark of VISA USA.
* OWASP is a registered trademark of the OWASP Foundation

All other products and company names may be trademarks of their respective owners. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Testing for Error Code (OTG-ERR-001)

2008-07-02T13:45:09Z

Gian: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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

== Description of the Issue ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ASP .net is a common framework from Microsoft used for developing web applications. IIS is one of the commonly used web server. Errors occur in all applications, we try to trap most errors but it is alomst impossible to cover each and every exception.

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

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

1. Inside Web.config customErrors section
2. Inside global.asax Application_Error Sub
3. at the the aspx or associated codebehind page in the Page_Error sub

'''Handling errors using web.config'''

<pre>
<customErrors defaultRedirect="myerrorpagedefault.aspx" mode="On|Off|RemoteOnly">
<error statusCode="404" redirect="myerrorpagefor404.aspx"/>
<error statusCode="500" redirect="myerrorpagefor500.aspx"/>
</customErrors>
</pre>

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

all the errors unless explicitly specified will be brought to defaultRedirect i.e. myerrorpagedefault.aspx.

a statuscode 404 will be shown myerrorpagefor404.aspx.

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

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

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

''''Handling errors in Page_Error sub'''

This is similiar to application error.

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

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

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

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

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

Fire up your browser and type a random page name

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

if the server returns

<pre>
The page cannot be found

HTTP 404 - File not found
Internet Information Services
</pre>

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

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

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

if the server returns

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

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

custom errors for .net are not configured.

== Black Box testing and example ==

'''Test:'''
<pre>
telnet <host target> 80
GET /<wrong page> HTTP/1.1
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1
</pre>
'''Test:'''
<pre>
1. Network problems
2. Bad configuration about host database address
</pre>
'''Result:'''
<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) '
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>
'''Test:'''
<pre>
1. Authentication failed
2. Credentials not inserted
</pre>
'''Result:'''

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

== Gray Box testing and example ==

'''Test:'''

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

== References ==

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

{{Category:OWASP Testing Project AoC}}

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

2008-07-02T08:18:35Z

Gian: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if data travel unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that are transmitted and to ensure that we are sending them towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends from the encryption algorithm used and from 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 our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, the tester wants to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually the user has to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS. This test is done to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

Suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, 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 data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible a lock, indicating the use of a secure protocol, and the fact that the url of that page starts with HTTPS.

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

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but in reality it is strongly suggested to use the POST method instead. This because, when the GET method is used, the url that it requests are easily available into, for example, the server logs exposing your sensitive data to information leakage.

<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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-02T08:11:01Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if data travel unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that are transmitted and to ensure that we are sending them towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends from the encryption algorithm used and from 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 our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, the tester wants to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually the user has to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS. This test is done to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

Suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, 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 data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but in reality it is strongly suggested to use the POST method instead. This because, when the GET method is used, the url that it requests are easily available into, for example, the server logs exposing your sensitive data to information leakage.

<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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T08:22:37Z

Gian: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if data travel unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that are transmitted and to ensure that we are sending them towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from 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 our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, the tester wants to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually the user has to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS. This test is done to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

Suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, 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 data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but in reality it is strongly suggested to use the POST method instead. This because, when the GET method is used, the url that it requests are easily available into, for example, the server logs exposing your sensitive data to information leakage.

<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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T08:16:25Z

Gian: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if data travel unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that are transmitted and to ensure that we are sending them towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from 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 our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, the tester wants to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually the user has to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS. This test is done to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T08:08:18Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if data travel unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that are transmitted and to ensure that we are sending them towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from 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 our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T07:59:42Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that the users are sending, are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T07:37:49Z

Gian: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

2008-07-01T07:35:55Z

Gian: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools'''

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

2008-07-01T07:34:04Z

Gian: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
HTTP/1.1: Security Considerations[http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html] 
'''Tools'''

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

2008-06-30T17:57:31Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T17:53:27Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into a web site, are transmitted using sure 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T17:52:52Z

Gian: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious users. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into a web site, are transmitted using sure 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T17:38:43Z

Gian: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious user. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into a web site, are transmitted using sure 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the last one for sensitive information transmissions. 
Then check with them if HTTPS is used in every sensitive transmission, like those in login pages, to avoid to an unauthorized user to read the data.

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T17:01:35Z

Gian: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious user. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into a web site, are transmitted using sure 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''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 they are displayed in clear in the URL and this entails a whole set of security issues. 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 message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than the HTTP one, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. But is not a good practice to use the GET method in these cases, because it is more easily exploitable.

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T16:36:42Z

Gian: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
The problem we are going to discuss is to verify that authentication data that we are sending are actually transferred via en encrypted channel to avoid being intercepted by some malicious user. The analysis focus simply on trying to understand if our data travel unencrypted from our web browser to the server or if the web application takes the appropriate security measures using a protocol like HTTPS. This protocol, like others that use encryption, is built on TLS/SSL to encrypt the data that we want to transmit and to ensure that we are sending them towards the desired site. Clearly, the fact that our traffic is encrypted does not necessarily means that it's completely safe. The security also depends from the encryption algorithm used and from the robustness of the keys that we are using. But this particular topic will not be addressed in this section, for a more detailed discussion on testing the safety of our TLS/SSL channel you can refer to chapter [[Testing for SSL-TLS]]. We will just try to understand if the data that we put into the web form, in order to log into a web site, are transmitted using sure 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. This page may use several methods to authenticate the user, but, apart which method it uses, we want to be sure that in the transaction that is established between clients (the web browsers) and server (the application itself), sensitive data (in this case username and password) are transmitted via en encrypted channel. In order to log into a web site, usually we have to fill a simple form that passes the inserted data with the POST method. What is less obvious is that these data can be passed using the HTTP protocol, and then in a non-secure way, or using HTTPS which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe to an insecure transmission), but then it actually sends data via HTTPS.We do this because we want to be sure that an attacker can not be able to retrieve sensitive information simply sniffing the net with a sniffer tool. Using HTTPS prevents packet sniffing and Man In The Middle attacks.
 

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

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

We suppose that our login page presents a form with fields User, Pass and the Submit button to authenticate and have access to the application. If we look at the header of our request with WebScarab, we 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 we can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password simply sniffing the net 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 data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.exmple.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.exmple.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.exmple.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.exmple.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people. We could also understand this, from the fact that in the window of our web browser is visible the lock that indicates the use of a secure protocol to access the page and that the url of that page starts with HTTPS.

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

Now we suppose to have a web page reacheable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data are transmitted in a secure way through encryption. 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 acessible from the home page through a login. So when we try to log, 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 field in the header (the page from which we came) it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So in this case we have no lock inside our browser window that tells us that we are using a secure connection, but in reality we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

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

2008-06-30T15:33:55Z

Gian: /* Black Box testing and example */

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

2008-06-30T15:02:11Z

Gian: /* Black Box testing and example */

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

2008-06-30T14:11:03Z

Gian: /* Brief Summary */

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

2008-06-30T14:06:01Z

Gian: /* Brief Summary */

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

2008-06-30T14:00:25Z

Gian: /* Description of the Issue */

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

2008-06-30T13:33:46Z

Gian: /* Brief Summary */