Should a ServiceWorker be able to read HttpOnly cookies?

[bsittler]

Existing server-side session cookie systems sometimes use HttpOnly cookies to avoid XSS-driven session cookie stealing. However, these single-cookie sessions (often implemented by server-side web app frameworks) are not easily portable to offline apps using ServiceWorker, because the ServiceWorker won't be able to read the cookie to perform a session check.

What if the server could opt the service worker script in to reading HttpOnly cookies by including a special response header in the worker script response, e.g. Service-Worker-HttpOnly-Cookies-Allowed: true ?

If we did this, we would also need a boolean in cookie-reading and cookie-monitoring APIs to determine whether a given operation reveals such cookies, e.g. cookieStore.get('COOKIENAME', {includeHttpOnly: true}

What do you think, @metromoxie @annevk @mikewest ?

Another intermediate option would be to allow the service worker to see one of the following:

• a keyed hmac/salted hash or other cryptographic fingerprint of the cookie value
• an opaque value for the cookie usable in comparison operations and in IndexedDB but not convertible to string
• a boolean indicating whether a given cookie is present

Also, returned cookie objects could indicate their httpOnly status alongside name and value

[FagnerMartinsBrack]

Is it worth adding a new layer if indirection for this? What is the problem of just telling the user to not use http-only cookies if they want to perform a session check using service workers for offline-first purposes?

[joelweinberger]

I think the concern is making it difficult for applications to upgrade to Service Workers from their current framework that uses HttpOnly cookies. It leaves developers with two choices: drop the HttpOnly (and thus lose its safety properties) or rework their application and framework to use dual session cookies when necessary.

While it may be that these are not palatable choices, I actually support this approach initially and seeing how bad it really is.

[annevk]

It seems dangerous to just use opt-in for the service worker though, since cookies have a scope that is greater than the origin.

[domenic]

Is this something we've actually gotten reports of from users of service worker, or is this a hypothetical upgrade pain? It seems premature to start adding advanced cookie API features, that go far beyond the powers granted to main-page cookie APIs, without very strong motivation in the form of developer demand.

[joelweinberger]

To clarify, I agree with @domenic. Save the pain and suffering with the API and see if it's actually a problem for developers.

[bsittler]

I agree with @domenic and @metromoxie on this too - my intent is indeed for the initial API proposal and specification to not allow reading HttpOnly cookies. The ability to read HttpOnly cookies has come up in offline conversations about this API with potential users of ServiceWorker, but my response to date has been "we're starting smaller with a document.cookie-equivalent security model".

I added this issue

• to track interest in the feature and
• to collect ideas on how such a thing might be made "safe enough" should developer demand become sufficient to justify the feature.

Knowing that an HttpOnly cookie used for sign-in purposes has expired/been overwritten is necessary to know when to delete the IndexedDB items and cache storage entries stored on behalf of the no-longer-signed-in user to avoid showing the wrong data.

Being able to read the values of HttpOnly cookies (regardless of their purpose) is necessary to implement full reverse-proxying in a ServiceWorker.

@annevk writes:

It seems dangerous to just use opt-in for the service worker though, since cookies have a scope that is greater than the origin.

I believe that because the web server which returns the custom header is also able to see these cookies there's no reason it shouldn't be able to delegate that ability to the service workers it installs. In the absence of such an API the web server could run a "cookie reflector" HTTP endpoint for the ServiceWorker, but it's harder to get the security right (i.e. accessible to the service worker but not to regular content scripts) for that, I think, and in any case it doesn't work when the service worker is running offline.

[bsittler]

One more bit, possibly non-obvious: if we allow a service worker (with server permission as indicated by a custom response header) to read HttpOnly cookies, this also gives service workers a place to store an encryption key and/or HMAC secret which cannot be seen by regular content scripts. The server can see it, but then again the server already has the ability to completely replace the worker. The key(s) can be used to securely store and retrieve data from IndexedDB without worrying about it being read (when using the encryption key) and/or modified (when using the HMAC secret) without the knowledge of the serviceworker, reducing somewhat the risk of e.g. auth token stealing due to unrelated XSS elsewhere on the same origin.

[craigfrancis]

My experience has been that developers think they need access to httpOnly cookies from JS/ServiceWorker, when they often don't (i.e. mostly focusing on the cookies value, rather than it's existence).

As to the original question about an offline SW checking if the user is logged on...

Seeing if the cookie exists (ok), or reading it's value (dangerous), will still be of little use, as a session cookie will typically have an expiry date far into the future (to account for browsers with an incorrect clock), or be marked as a session cookie (delete when the browser closes), so you really need to check the value against the server to see if they are actually logged in.

If you need this behaviour, then a website is better served with 2 cookies, one httpOnly with the secret key for the session (that JS/SW should never have access to), and a non-httpOnly cookie that simply says they are logged on (maybe it could store their username, or user id?).

I'd be very concerned if we allowed a SW to read httpOnly cookies.

[pwnall]

The current explainer tries to clarify that the Async Cookies API doesn't intend to add new capabilities over document.cookie. Exposing HttpOnly cookies to script would be a new capability. Happy to reopen the discussion if developer feedback warrants it.