Site Survey
Methodology
ISE tested thirty secure, password-protected sites that displayed sensitive personal information in a web browser. This involved accessing SSL-protected websites as an authorized user, logging out of the site, and closing the Firefox browser. Then, ISE reopened the browser, placed it in offline mode, and checked the disk cache for entries containing sensitive data.
Initial Results
As of April 25, 2013, twenty-one of the thirty sites tested were not sending the Cache-Control: no-store header required by the HTTPS standard to prevent disk caching of sensitive data. Some were not sending any caching-related headers at all, while others were sending caching headers that prevent disk caching only in Internet Explorer, or other headers not relevant to web browser caches.
The following sites sent sensitive information with both of the headers Cache-Control: no-cache, and Pragma: no-cache, which prevent disk caching in Internet Explorer, but not Firefox or Chrome:
| Site | Sensitive Information |
|---|---|
| ADP | Full earnings statements, including names, addresses, the last four digits of the employee's social security number, and financial data |
| BGE | Customer names, addresses, account numbers, and balances |
| M & T Bank Wealthcare | Customer names, account numbers, and balances |
| Scottrade | Account numbers and balances |
| TreasuryDirect | Customer names, the last four digits of the account holder's social security number, addresses, and telephone numbers |
| Verizon Wireless | Call details |
Table 1. Sites sending sensitive information with both the headers Cache-Control: no-cache, and Pragma: no-cache, which only prevent disk caching in Internet Explorer.
The following sites sent sensitive information with the header Cache-Control: no-cache which prevents disk caching in Internet Explorer, but not Firefox or Chrome:
| Site | Sensitive Information |
|---|---|
| BB&T | Customer names, email addresses, the last four digits of account numbers, and account balances |
| Liberty Mutual | Customer names, policy numbers, property addresses, and policy limits |
| PayPal | Customer names, email addresses, addresses, and phone numbers |
Table 2. Sites sending sensitive information with the header Cache-Control: no-cache, which only prevents disk caching in Internet Explorer.
The following sites sent sensitive information with the header Cache-Control: private, which has no effect on whether or not a web browser caches the information to disk:
| Site | Sensitive Information |
|---|---|
| Allstate | Auto insurance policy documents |
| eBillity | Worker summary reports |
| eRenterPlan | Customer names, addresses, and telephone numbers |
Table 3. Sites sending sensitive information with the header Cache-Control: private, which has no effect on disk caching in web browsers.
The following sites sent sensitive information without any cache-related HTTP headers at all:
| Site | Sensitive Information |
|---|---|
| Argus Health | Customer names and pharmacy claims, including the names of prescription medications |
| Boscov's Charge Card | Full account statements, including the full card number |
| Equifax | Full credit reports and credit scores |
| GEICO | Customer names, addresses, the customer date of birth, and the last four digits of the customer's social security number |
| MetLife | Customer names, policy numbers, policy amounts, and beneficiary names |
| PNC Bank | Check images |
| T. Rowe Price | 401(k) balances |
| Toyota Financial | Customer names, addresses, account numbers, and VINs |
| Trade King | Account numbers and balances |
Table 4. Sites sending sensitive information without caching-related HTTP headers.
Below are screenshots of some of the data we recovered from the disk cache.
Figure 1.Credit report from Equifax.
Figure 2.Prescription history from Argus.
Figure 3.Earnings statement from ADP.
Figure 4.Account information from TreasuryDirect.
Figure 5.Boscov's Charge Card Account statement with account number.
Figure 6.Check image from PNC.
Updates
We notified each company by email to the security– or phishing–related email address, or when email was not available, using a web-based contact form. The following companies acknowledged our advisories with a non-automated response:
- Argus Health
- M & T Bank
- PayPal
The following companies have made at least some progress in correcting the issue:
- BB&T. The account summary page is now sending Cache-Control: no-store, but check images are still sent with inadequate protections.
Observations and Concerns
We believe that the amount of personal data that is currently being written to the disk cache when visiting these sites is alarming. It is important to note, however, the distinction between a user consciously selecting a "save to disk" option, e.g., to save a bank statement, and content silently being written to the disk cache without users' knowledge. Non-technical users likely believe that if, after visiting a site and viewing personal data, they logout and close their browsers, that their data will be safe. Our findings prove this assumption incorrect in 70% of the cases tested.
Based on the quantity of sites (twelve of twenty-one) that sent at least one cache-related header, even if it was not the one mandated by the standard to prevent disk caching, we do not believe that it is intended by these industries that this content be written to the disk cache. More significantly, the maintainers of these sites may erroneously believe that they have set the required headers to prevent disk caching, based on outdated and incorrect information published on the Internet. One tutorial [11] correctly states the purpose of all of these headers, but does not put them in the proper context with regard to HTTPS, stating “SSL pages are not cached (or decrypted) by proxy caches,” which, while true for proxies, does not address the behavior of browsers. An OWASP page [12] incorrectly asserts that “If a web page is delivered over SSL, no content can be cached.” When even the security community makes outdated and incorrect assumptions about this issue, it is unrealistic that more generally-focused web developers will do better.
Web browser authors, with the most striking example being Mozilla, seem unconcerned with shifting the responsibility of discretion as to which HTTPS pages are safe to disk cache to the server. A comment on the bug report involving the change to Firefox 4's SSL caching policy by a member of Mozilla Corporation's security team stated “Among sites that don't use cache-control:no-store, the correlation between "SSL" and "sensitive" is very low” [8]. Our findings show that this assertion does not hold when real-world sites are examined, even two years after the change.
The fact that the unencrypted, disk cached data is only stored on the user's personal machine should not be discounted. The possibilities for this information to be exposed are numerous: malware infections, theft of laptops and mobile devices, theft of physical backup media or compromise of “cloud” backup services, shared machines and user accounts, and of course, shared computers in libraries, hotels, and Internet cafes. An Intel-sponsored Ponemon Institute study estimated the cost of recovering from the loss or theft of a single laptop as $49,246 [13], and a Lookout Mobile Security study estimated that lost and stolen phones cost consumers more than $30 billion in 2012 [14].