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 Sensitive information sent via unencrypted channels (OTG-CRYPST-003)"

From OWASP
Jump to: navigation, search
m
(some corrections, some clarifications)
Line 3: Line 3:
  
 
== Brief Summary ==
 
== Brief Summary ==
−
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanist must have not limitations and vulnerabilities, as explained in the broader article "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection" [1] and in other OWASP documentation [2], [3], [4], [5].In fact consider adding a security control or safeguard is an addition to the attack surface.
+
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities, as explained in the broader article [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)] [1] and in other OWASP documentation [2], [3], [4], [5]. As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. Some examples for sensitive data are:
−
However a specific test is needed to ensure if the control is missing and sensitive data is transmitted via unencrypted channel. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. Such as:
+
* Information used in Authentication (e.g. Credentials, PINs, Session identifiers, Tokens, Cookies…)
−
* Information used in Authentication (e.g. Credentials, PINs, Session Ids, Tokens, Cookies…)
+
* Information protected by Laws, Regulations or specific organizational Policy (e.g. Credit Cards, Customers data)  
−
* Information protected by Laws, Regulations or specific Organization’s Policy (e.g. Credit Cards, Customers data)  
 
  
 
== Description of the Issue ==
 
== Description of the Issue ==
−
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.
+
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is considered a security risk. Some examples are Basic authentication which sends authentication credentials in plain-text over HTTP, form based authentication credentials sent via HTTP, or plain-text transmission of any other information considered sensitive due to regulations, laws, organizational policy or application business logic.  
  
−
== Black Box testing and example ==
+
== Black Box testing and examples ==
−
Various typologies of information, which must be protected, can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS.
+
Various types of information which must be protected, could be transmitted by the application in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS, or whether weak cyphers are used. See more information about insecure transmission of credentials [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure] [3] or insufficient transport layer protection in general [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection Top 10 2010-A9-Insufficient Transport Layer Protection] [2].
−
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2].
 
  
−
=== Example 1. Basic Authentication over HTTP ===
+
=== Example 1: Basic Authentication over HTTP ===
−
A typical example is the usage of Basic Authentication over HTTP. Also, with Basic Autentication credentials are encoded and not encrypted into HTTP Headers, using curl [5].
+
A typical example is the usage of Basic Authentication over HTTP. When using Basic Authentication, user credentials are encoded rather than encrypted, and are sent as HTTP headers. In the example below we use curl [5] to test for this issue. Note how the application uses Basic authentication, and HTTP rather than HTTPS
  
 
<pre>
 
<pre>
Line 31: Line 29:
 
</pre>
 
</pre>
  
−
=== Example 2. Form Authentication over HTTP ===
+
=== Example 2: Form-Based Authentication Performed over HTTP ===
−
Another typical example is forms containing passwords transmitted over HTTP. It is possible to find the “http://” or “//” as the protocol in “action” attribute of the form and some input containing passwords or other data.
+
Another typical example is authentication forms which transmit user authentication credentials over HTTP. In the example below we see HTTP being used in the "action" attribute of the form. It is also possible to see this issue by examining the HTTP traffic with an interception proxy.
  
 
<pre>
 
<pre>
Line 42: Line 40:
 
</pre>
 
</pre>
  
−
=== Example 3. Cookie containing Session ID over HTTP ===
+
=== Example 3: Cookie Containing Session ID Sent over HTTP ===
−
Session ID Cookie must be transmitted over protected channels. If Cookie have NOT Secure flag [6] it is possible to transmit unencrypted. In this case it can be eavesdropped.
+
The Session ID Cookie must be transmitted over protected channels. If the cookie does not have the secure flag set [6] it is permitted for the application to transmit it unencrypted.. Note below the setting of the cookie is done without the Secure flag, and the entire login process is performed in HTTP and not HTTPS.  
  
 
<pre>
 
<pre>

Revision as of 20:35, 22 April 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


Brief Summary

Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities, as explained in the broader article Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002) [1] and in other OWASP documentation [2], [3], [4], [5]. As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. Some examples for sensitive data are:

  • Information used in Authentication (e.g. Credentials, PINs, Session identifiers, Tokens, Cookies…)
  • Information protected by Laws, Regulations or specific organizational Policy (e.g. Credit Cards, Customers data)

Description of the Issue

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

Black Box testing and examples

Various types of information which must be protected, could be transmitted by the application in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS, or whether weak cyphers are used. See more information about insecure transmission of credentials Top 10 2013-A6-Sensitive Data Exposure [3] or insufficient transport layer protection in general Top 10 2010-A9-Insufficient Transport Layer Protection [2].

Example 1: Basic Authentication over HTTP

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

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

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

Example 2: Form-Based Authentication Performed over HTTP

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

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

Example 3: Cookie Containing Session ID Sent over HTTP

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

https://secure.example.com/login

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

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

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

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

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

References

OWASP Resources

Tools

  • [5] curl can be used to check manually for pages
Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&oldid=173232"