263290 - view-source: protocol allows viewing "cache-control: no-store" pages that are no longer being displayed

Status: NEW

(Core :: Networking: Cache, defect, P3)

Description

[Jesse Ruderman]

We store "no-store" pages in the cache.  They're marked in such a way that they
don't appear for the back button, which is good.  But the view-source protocol
can be used to view them, even after the browser is no longer displaying the
page.  This eliminates the primary security benefit of keeping session history
from using no-store items.

Steps to reproduce:
1. Load http://www.sacarny.com/blog/index.php?p=105.
2. Close the page.
3. Load view-source:http://www.sacarny.com/blog/index.php?p=105.

Result: Get the same copy.  (The time at the bottom is the same.)

Expected: Get a new copy.

http://www.ietf.org/rfc/rfc2616.txt says: "no-store. ... MUST make a best-effort
attempt to  remove the information from volatile storage as promptly as possible
after forwarding it."

Possible approaches to fixing this security hole:

A) Fix bug 182712 (never expire cache data for open document) and evict no-store
items as soon as they're unpinned.

B) Make it so the View Source menu item can access no-store items but manually
entered view-source: addresses can't.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Frankly, I would suggest just killing manual entry of view-source URIs
altogether.  That is, only allow chrome to load view-source URIs (via
CheckLoadURI).  The reason is that neither of your approaches really works:

> A) Fix bug 182712 (never expire cache data for open document) and evict
> no-store items as soon as they're unpinned.

They won't be unpinned as long as the session history for them exists, so
closing the window is required to "really" forget them.

> B) Make it so the View Source menu item can access no-store items but manually
> entered view-source: addresses can't.

There is no way to tell the two cases apart from within the view-source code,
really.

What I _am_ surprised by is that just entering the URI works.  You're not
getting an SHEntry in that case, so I would fully expect to see it fail, since
the data _is_ marked as expired in the cache... what gives?

Comment 2

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

The vulnerability here is in an internet-cafe type situation, where someone
could come along behind you and see these sensitive pages.

Comment 3

[[e-mail]]

(In reply to comment #1)
>>A) Fix bug 182712 (never expire cache data for open document) and evict
>>no-store items as soon as they're unpinned.
>
>They won't be unpinned as long as the session history for them exists, so
>closing the window is required to "really" forget them.

Perhaps he means "evict a no-cache page as soon as you navigate away"?

Comment 4

[Boris Zbarsky [:bzbarsky]]

The cache has no concept of "navigate away", nor does the HTTP implementation,
and the layers that have such a concept should not need to know that things like
no-store exist.

Comment 5

[[e-mail]]

It's getting late, but I was expecting the docShell to have a reference to the
cache entry, which it would drop, triggering the eviction, or something...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm... that may be doable.... (with the cache token stuff, once that gets
implemented).

Comment 7

[Darin Fisher]

I think we should be able to solve this by differentiating a view-source:http://some/url entered in the URL bar from a view-source of the current URL.

Comment 8

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

Since this is not a remote exploit should we remove the security-sensitive flag?

Comment 9

[Darin Fisher]

-> reassign to default owner

Comment 10

[Jesse Ruderman]

Sure, that sounds reasonable.

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258