Difference between revisions of "Testing for Browser cache weakness (OTG-AUTHN-006)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == <br> ..here: we describe in "natural language" what we want to test. <br> == Description of the Issue == <br> ...her...")
 
Line 1: Line 1:
 
{{Template:OWASP Testing Guide v4}}
 
{{Template:OWASP Testing Guide v4}}
  
 +
<b>Note:</b> Currently, this is basically a replica of the browser cache portions of the "Testing for Logout and Browser Cache Management (OWASP-AT-007)" Test Case from OWASP v3.
  
 
== Brief Summary ==
 
== Brief Summary ==
 +
In this phase we check that the server correctly instructs the browser to not cache sensitive data.
 
<br>
 
<br>
..here: we describe in "natural language" what we want to test.
+
 
<br>
+
 
== Description of the Issue ==  
 
== Description of the Issue ==  
<br>
 
 
...here: Short Description of the Issue: Topic and Explanation
 
...here: Short Description of the Issue: Topic and Explanation
 
<br>
 
<br>
 +
 
== Black Box testing and example ==
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' <br>
+
'''The Browser "Back" Button'''<br>
...<br>
+
The first (and simplest) test consists of logging out and then hitting the 'back' button of the browser, to check whether previously entered sensitive information can be accessed whilst unauthenticated.
'''Result Expected:'''<br>
+
If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header).
...<br><br>
+
<br>
 +
 
 +
'''Cached Pages'''<br>
 +
Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers. "Cache-Control: no-cache, no-store" coupled with "Expires: 0" and "Pragma: no-cache" is generally robust although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include: must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0.
 +
<br>
 +
<pre>
 +
HTTP/1.1:
 +
Cache-Control: no-cache
 +
</pre>
 +
<pre>
 +
HTTP/1.0:
 +
Pragma: no-cache
 +
Expires: <past date or illegal value (e.g., 0)>
 +
</pre>
 +
<br>
 +
For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
 +
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:
 +
 
 +
* Mozilla Firefox:
 +
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
 +
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache
 +
 
 +
* Internet Explorer:
 +
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 +
<br>
 +
 
 +
== Gray Box testing and example ==
 +
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 +
<br>
 +
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
...<br>
+
...
 +
<br>
 +
 
 
'''Tools'''<br>
 
'''Tools'''<br>
...<br>
+
...
 +
<br>

Revision as of 04:06, 25 November 2013

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

Note: Currently, this is basically a replica of the browser cache portions of the "Testing for Logout and Browser Cache Management (OWASP-AT-007)" Test Case from OWASP v3.

Brief Summary

In this phase we check that the server correctly instructs the browser to not cache sensitive data.

Description of the Issue

...here: Short Description of the Issue: Topic and Explanation

Black Box testing and example

The Browser "Back" Button
The first (and simplest) test consists of logging out and then hitting the 'back' button of the browser, to check whether previously entered sensitive information can be accessed whilst unauthenticated. If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header).

Cached Pages
Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers. "Cache-Control: no-cache, no-store" coupled with "Expires: 0" and "Pragma: no-cache" is generally robust although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include: must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0.

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


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

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


Gray Box testing and example

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

References

Whitepapers
...

Tools
...