609622 - Possible security issue with back button & cache with https server

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Ketan]

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

[Benjamin Smedberg]

AIUI this is intentional: we cache HTTPS content by default unless you specifically send no-cache headers. cc'ing biesi/bz for confirmation.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Jesse Ruderman]

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.