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

From OWASP
Jump to: navigation, search
(Black Box testing and example)
(Black Box testing and example)
Line 14: Line 14:
  
 
== Black Box testing and example ==
 
== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. Aniway you can use any web proxy that you prefer.
+
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''' <br>
 
'''Case study: Sending data with POST method through HTTP''' <br>
Line 61: Line 61:
 
</pre>
 
</pre>
  
'''Result Expected:'''<br>
+
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.
 +
 
 +
 
 
...<br><br>
 
...<br><br>
  

Revision as of 10:33, 30 June 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Contents


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:

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

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&Username=test&Password=test

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.


...

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...