1443662 - Script can set values for httponly cookies (that will only be available to script)

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect, P2)

Description

[u408661]

This is almost the same as bug 1421324 but it has kind of the opposite order of str:

1. Set an HttpOnly cookie named myHttpOnlyCookie
2. Notice that document.cookie does not have that value
3. Without reloading, set document.cookie = "myHttpOnlyCookie=wtfisgoingonhere"
4. Notice that now document.cookie has the value set in step 3

None of the other major browsers behave this way (the value you get from document.cookie in step 4 is the same as whatever you got in step 2). This is another regression from bug 1331680. The fix isn't quite as simple, though (and may, in fact, involve undoing some of the work from bug 1421324).

Not 100% sure this is security-sensitive, but its cousin bug 1421324 was, so I'm marking this one as such just in case.

Comment 1

[Daniel Veditz [:dveditz]]

We may, in fact, allow overwriting an httponly cookie with a non-httponly cookie. Is it specified that we shouldn't do that? Seems like we shouldn't, but I can imagine that unless it's specified we might have just treated a cookie as a cookie. We had to do a bunch of work to make a non-secure cookie not overwrite a secure cookie last year and I imagine if we had similar protection for httponly we would have just used something based on that instead of starting from scratch.

Comment 2

[u408661]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> We may, in fact, allow overwriting an httponly cookie with a non-httponly
> cookie. Is it specified that we shouldn't do that? Seems like we shouldn't,
> but I can imagine that unless it's specified we might have just treated a
> cookie as a cookie. We had to do a bunch of work to make a non-secure cookie
> not overwrite a secure cookie last year and I imagine if we had similar
> protection for httponly we would have just used something based on that
> instead of starting from scratch.

So we definitely allow it via http, however this is specific to writing the cookie via script. (Note that it's *not* overwritten - network requests still get the HttpOnly value - but it *is* shadowed in script with whatever is set through document.cookie) Prior to bug 1331680 we didn't allow shadowing an HttpOnly cookie via script.  After that landed, however, we do. No other browser I tested (Safari, Chrome, Edge) allows this - they all silently drop the cookie set by script on the floor.

Let me see if I can make this a bit more explicit, so we're all on the same page (I fear I may not have described it well in the initial report, and may not be describing it well here):

1. Navigate to a page that sends the response header:
Set-Cookie: httpOnlyCookie=somevalue; HttpOnly

2. In script on that page (I used dev tools):
document.cookie // returns ""
document.cookie = "httpOnlyCookie=thisshouldnotappear"
document.cookie // now returns "httpOnlyCookie=thisshouldnotappear", should keep returning "" as it does on Safari, Chrome, Edge, and Firefox < 57

3. Navigate to some other page on the same origin, firefox sends the (correct) header
Cookie: httpOnlyCookie=somevalue

Now, if later we were to navigate to some page on the same origin that sends
Set-Cookie: httpOnlyCookie=someothervalue
Then in step 2, the first read of document.cookie would (correctly) return "httpOnlyCookie=someothervalue", and we could (correctly) change the value of the cookie, and that would (correctly) be sent over the network if we then did step 3 again.

I don't know if this is specified anywhere, but it's the way everyone else behaves (and we did in the past), so we should be consistent.

Comment 3

[Daniel Veditz [:dveditz]]

This direction doesn't seem like a security bug -- the page can read back a value (instead of no value) that it set itself. We can handle as a public bug.

Comment 4

[u408661]

This is being taken care of in bug 1440462