Possible security issue with back button & cache with https server

RESOLVED INVALID

Status

()

Core
Networking: HTTP
RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: Ketan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

We're in the process of building a website for a client and we can across what could be a security issue. We have a payment form on a https server where the user enters their credit card details. On submission, the payment is processed and the site returns the transaction data on the same processing page (e.g. form is on form.php which posts to process.php - it is process.php that would show the result). At this point we are also destroying any sessions that we created.

Clicking the back button on this process page actually displays all the details (even though the session has been destroyed), credit card details and everything. Other browsers clear the cache and show the correct page (empty basket), but we've worked around this by using the no-cache meta tag for Firefox.

Reproducible: Always

Steps to Reproduce:
1. Post a form on https
2. Hit back button
3. See everything
Actual Results:  
We had access to all the users details

Expected Results:  
Clear the cache and not stored any variables or session data (which had been cleared)

Comment 1

7 years ago
AIUI this is intentional: we cache HTTPS content by default unless you specifically send no-cache headers. cc'ing biesi/bz for confirmation.
Component: Security → Networking: HTTP
Product: Firefox → Core
QA Contact: firefox → networking.http
That's correct.  HTTPS content is cached like any other content, subject to the relevant HTTP headers.

Futhermore, we keep history state for pages outside the HTTP cache also, unless those pages are no-store or SSL+no-cache.  This is presumably what you're really seeing if the credit card details are visible, since those aren't part of the page content you send, right?

Updated

7 years ago
Group: core-security
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID

Comment 3

7 years ago
It's intentional that we don't treat HTTPS specially.  See bug 531801 and bug 424872.  You're correct to use a cache-control header to modify the behavior.
You need to log in before you can comment on or make changes to this bug.