This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)"

From OWASP
Jump to: navigation, search
(Brief Summary)
(Example 3: sending data with POST method via HTTPS on a page reachable via HTTP)
 
(38 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
  
'''This is a draft of a section of the new Testing Guide v3'''
+
== Summary ==
 +
Testing for credentials transport means verifying that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site.
  
== Brief Summary ==
+
 
<br>
+
Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section.
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.
+
 
 +
 
 +
For a more detailed discussion on testing the safety of TLS/SSL channels refer to the chapter [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002)|Testing for Weak SSL/TLS]]. Here, the tester will just try to understand if the data that users put in to web forms in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker.  
 
<br>
 
<br>
  
== Description of the Issue ==
 
<br>
 
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.
 
<br>
 
  
== Black Box testing and example ==
+
Nowadays, the most common example of this issue is the log in page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log in to a web site, the user usually has to fill a simple form that transmits the inserted data to the web application with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, which transmits the data in a non-secure, clear text form, or using the HTTPS protocol, which encrypts the data during the transmission. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the network with a sniffer tool.
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.
+
 
 +
==How to Test==
 +
=== Black Box testing ===
 +
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.
 +
 
  
 +
====Example 1: Sending data with POST method through HTTP====
  
'''Case study: Sending data with POST method through HTTP''' <br>
+
Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this:<br>
  
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:<br>
 
 
<pre>
 
<pre>
 
POST http://www.example.com/AuthenticationServlet HTTP/1.1
 
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Line 38: Line 41:
 
</pre>
 
</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.
+
 
 +
From this example the tester can understand that the POST request sends the data to the page ''www.example.com/AuthenticationServlet'' using HTTP. Sothe data is transmitted without encryption and a malicious user could intercept the username and password by simply sniffing the network with a tool like Wireshark.
  
  
'''Case study: Sending data with POST method through HTTPS'''
+
====Example 2: 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:
+
Suppose that our web application uses the HTTPS protocol to encrypt the data we are sending (or at least for transmitting sensitive data like credentials). In this case, when logging on to the web application the header of our POST request would be similar to the following:
  
 
<pre>
 
<pre>
Line 62: Line 66:
 
Command=Login&User=test&Pass=test
 
Command=Login&User=test&Pass=test
 
</pre>
 
</pre>
 +
  
 
We can see that the request is addressed to
 
We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
+
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol. This ensures that our credentials are sent using an encrypted channel and that the credentials are not readable by a malicious user using a sniffer.
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'''
+
====Example 3: 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:
+
Now, imagine having a web page reachable via HTTP and that only data sent from the authentication form are transmitted via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services that are publicly available, without identification, but the site also has a private section accessible from the home page when users log in. So when we try to log in, the header of our request will look like the following example:
  
 
<pre>
 
<pre>
POST https://www.example.com:443/login.do HTTP/1.1
+
POST http://www.example.com/homepage.do
Host: www.example.com
+
Host: http://www.example.com/homepage.do
 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
 
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: text/xml,application/xml,application/xhtml+xml,text/html
Line 90: Line 94:
 
</pre>
 
</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.
 
  
 +
We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the Referer-header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow [http://www.thoughtcrime.org/software/sslstrip/ SSLStrip] attacks (a type of [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle] attack)
  
'''Case study: Sending data with GET method through HTTPS'''
+
====Example 4: 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.  
+
In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because the data is displayed in clear text in the URL and this causes a whole set of security issues. For example, the URL that is requested is easily available from the server logs or from your browser history, which makes your sensitive data retrievable for unauthorized persons. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead.  
  
 
<pre>
 
<pre>
Line 112: Line 116:
 
</pre>
 
</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 ==  
+
You can see that the data is transferred in clear text in the URL and not in the body of the request as before. But we must consider that SSL/TLS is a level 5 protocol, a lower level than HTTP, so the whole HTTP packet is still encrypted making the URL unreadable to a malicious user using a sniffer. Nevertheless as stated before, it is not a good practice to use the GET method to send sensitive data to a web application, because the information contained in the URL can be stored in many locations such as proxy and web server logs.
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.<br>
+
 
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.
+
 
 +
=== Gray Box testing ===  
 +
Speak with the developers of the web application and try to understand if they are aware of the differences between HTTP and HTTPS protocols and why they should use HTTPS for transmitting sensitive information. Then, check with them if HTTPS is used in every sensitive request, like those in log in pages, to prevent unauthorized users to intercept the data.
 +
 
 +
 
 +
==Tools==
 +
* [[OWASP WebScarab Project|WebScarab]]
 +
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]
 +
 
  
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html<br>
+
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
'''Tools'''<br>
+
* [http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html SSL is not about encryption]<br>
* WebScarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br>
 

Latest revision as of 05:52, 30 December 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Summary

Testing for credentials transport means verifying that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site.


Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section.


For a more detailed discussion on testing the safety of TLS/SSL channels refer to the chapter Testing for Weak SSL/TLS. Here, the tester will just try to understand if the data that users put in to web forms in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker.


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

How to Test

Black Box testing

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


Example 1: Sending data with POST method through HTTP

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this:

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


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


Example 2: Sending data with POST method through HTTPS

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

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


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


Example 3: sending data with POST method via HTTPS on a page reachable via HTTP

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

POST http://www.example.com/homepage.do
Host: http://www.example.com/homepage.do
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


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

Example 4: Sending data with GET method through HTTPS

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

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"


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


Gray Box testing

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


Tools


References

Whitepapers