If they find pages that contain critical information but that fail to instruct the browser not to cache their content, they know that sensitive information will be stored on the disk, and they can double-check this simply by looking for the page in the browser cache. Cache-Control: must-revalidate, max-age=0, s-maxage=0Įxpires: "past date or illegal value (e.g., 0)"įor instance, if testers are testing an e-commerce application, they 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.These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the file system. Such a directive can be issued in the HTTP response headers with the following directives: In order to do that, they can use a proxy (such as OWASP ZAP) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Here testers check that the application does not leak any sensitive data into the browser cache.
The Back button can be stopped from showing sensitive data. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled. If these pages contain sensitive data, it means that the application did not forbid the browser from storing it.Īuthentication does not necessarily need to be involved in the testing. If by pressing the Back button the tester can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. Then the tester clicks the Back button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated. The first and simplest test consists of entering sensitive information into the application and logging out. However, they share the same weakness of presenting previously displayed sensitive information. The cache and the history are two different entities. Technically, the Back button is a history and not a cache (see Caching in HTTP: History Lists). Review if access can occur without authorization.Review if the application stores sensitive information on the client-side.If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser’s cache or by simply pressing the browser’s Back button. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved. Caching is used to improve performance, so that previously displayed information doesn’t need to be downloaded again.
In this phase the tester checks that the application correctly instructs the browser to not retain sensitive data.īrowsers can store information for purposes of caching and history.
Home > Latest > 4-Web Application Security Testing > 04-Authentication Testing Testing for Browser Cache Weaknesses ID
0 kommentar(er)
