Add a bit to Opaque Responses to distinguish redirects

[slightlyoff]

(apologies if this is a dupe)

@sirdarckcat has brought up an issue (documented here: http://sirdarckcat.blogspot.de/2015/05/service-workers-secure-open-redirect.html ) that seems like it'd be mostly solved through the addition of a single bit to Response objects which notes if the content is the result of a redirect.

At the webappsec f2f today in Berlin, the group there seems to agree that exposing this bit on Responses doesn't leak any new information; it's observable via CSP + iframes already.

/cc @jakearchibald @jungkees @annevk @metromoxie @hillbrad

[annevk]

You can observe redirects with fetch(url, {redirect:"error"}) too. I guess this helps in the case where you have fetch(crossOriginURL, {mode:"no-cors"}) and there's potentially a redirect, because either way you'd get an opaque response back. And maybe in the fetch(sameOriginURL, {mode:"no-cors"}) case if you're only looking at the response and not the url.

It seems safer however to use fetch(url, {redirect:"error"}) as in that case you'll never get a response you didn't expect.

[slightlyoff]

Forcing another set of RTT's to get just the single bit of data (that it was a redirect) is pretty bad, particularly in the cases where it might be a POST or non-idempotent operation.

[annevk]

What I'm saying is that you would always use redirect:"error". Not that you would use that to detect a redirect. (Using that and window:null would actually be more efficient for transmitting bodies too. As we can avoid teeing the body.)

What I'm wondering is why you would suddenly care about this when you get to a response while you don't care about it when making a request. What kind of scenario that helps.

[slightlyoff]

No, I understand what you were saying; I don't think it's easy or reasonable. There are many systems that legitimately have redirects for "own content" but have off-origin redirects for navigation exfiltration; i.e. a secure open redirector to filter out referrer information.

[annevk]

Sure, but in that scenario you simply would not cache opaque responses.

[sirdarckcat]

The problem is that some sites are likely to install a SW that caches all requests it sees.

[annevk]

Sure, but that's also a problem without redirects...

[sirdarckcat]

why is it a problem without redirects? in what other case would a cached
response be dangerous?

in this case it seems dangerous since most websites have open redirects, so
an attacker could fool a SW to cache a CORS-enabled Response object for a
same-origin Request.

[annevk]

Well, in that case you can already figure out you're redirected right? Since for "cors" responses you can just check their url.

[sirdarckcat]

The argument goes as follows:

1. Many websites have open redirects (facebook, google, yahoo, outlook,
   etc..). Essentially everyone that uses OAuth or OIC protocols has an open
   redirect by design.
2. It's likely that both, large and small sites will do cache-all
   policies. See this SW, for example:
   https://www.google.com/_/chrome/newtab-serviceworker.js

When developers code these SW, it's not expected for them to have to check
for redirects, because it's not really intuitive, and as a result would
create an XSS in that site.

[annevk]

Right, I understand the attack, don't worry, but if you look at OP it's suggesting to add a bit so you can figure out if the response is a redirect. You can already do this in most cases and if you don't want redirects to be followed you can accomplish that too, as I pointed out. It seems you want something else. It would help if you stated what you want.

[sirdarckcat]

Oh, I thought that the bit in the Request would be part of the algorithm for Cache.match(), but reading this once again, it seems like this is a bit in the response..

[annevk]

We could certainly add restrictions to the Cache API, but this repository is about fetch() (and Fetch in general). I think if you use fetch() and you're worried about redirects, you ought to use fetch(url, {redirect:"error"}).

[sirdarckcat]

Right, that makes sense. It seems the OP is about making something like a Request. makeAllCrossOriginRedirectsOpaque=true; Which is a new idea for mitigating this, and I had assumed it was the Cache.match one :-).

[annevk]

I'm pretty sure OP wants response.hasBeenRedirected (and it to work for all responses). (Making responses opaque doesn't really mitigate the attack I think.)

[sirdarckcat]

An opaque response wouldn't be renderable, which would mitigate at least the XSS risk. It would still be possible to cache JS/Images, etc but they are usually not dangerous (one exception would be shared workers, but they can't be installed cross-origin).

[annevk]

Why would you prefer making responses opaque over simply getting a network error? Or getting a "opaqueredirect" response when you're redirected?

[jakearchibald]

The attack demo isn't working (not https) so here's what I think the attack is, if I'm wrong, the rest of my post is nonsense.

• Good site's SW will serve from cache if it can
• Good site's SW will cache content it gets from the network, for a set of urls which includes an anywhere-redirect
• Good site allows users to create a CORS request to the anywhere-redirect (via fetch/xhr indirectly, <img crossorigin> etc)
• Evil player can use this to get their evil-site content cached against a good-site request
• Navigating to this url will cause the evil-site content to be served as a response on the good-site origin

If this response contains script, it's running on the good-site origin.

If that's the attack, I don't see how a "this came from a redirect" bit can help, as this information is already in response.url, except in the case of opaque responses. That wouldn't work for navigations, although it would work for <script>. This would only be a problem if the good-site had a <script src> pointing to the global redirect that was pointing to the evil-site, so security would be broken without SW.

Disallowing cross-origin CORS responses in response to "same-origin" navigation requests would help mitigate the navigation case. @annevk - we were trying to think of why we might need this restriction.

Another possibility (although I'm not sure we need it) is a redirect mode of "follow-same-origin".

[wanderview]

Disallowing cross-origin CORS responses in response to "same-origin" navigation requests would help mitigate the navigation case. @annevk - we were trying to think of why we might need this restriction.

This would require blocking synthetic responses for "same-origin" requests as well, right? Its trivial to convert a CORS response into a synthetic response.

[annevk]

Disallowing cross-origin CORS responses in response to "same-origin" navigation requests would help mitigate the navigation case.

Wait, how did you end up here from where you started? Does in this scenario the service worker override the default of not following redirects? Doesn't make much sense to me.

[annevk]

Another possibility (although I'm not sure we need it) is a redirect mode of "follow-same-origin".

Can you explain how this is different from setting mode to "same-origin" and redirect mode to "follow"?

[jakearchibald]

Wait, how did you end up here from where you started?

This was resolved in IRC, but for the record: The bad stuff goes into the cache via a cors request, and comes back out via a client request. The cache would end up with an entry where the key was "good site" and the value was "bad site". Then when the navigation happens, the "bad site" entry is pulled out.

Can you explain how this is different from setting mode to "same-origin" and redirect mode to "follow"?

I thought @slightlyoff was wanting to retain "legitimate" redirects. #79 (comment)

[jakearchibald]

There's a further question on whether we should allow entries in the cache where request.url has a different origin to response.url, unless the response is synthetic

[annevk]

I thought @slightlyoff was wanting to retain "legitimate" redirects.

Sure, but how is your proposal different in terms of processing from what I wrote?

There's a further question on whether we should allow entries in the cache where request.url has a different origin to response.url

As I said elsewhere, this is getting into nutty territory and doesn't defend against same-origin -> cross-origin -> same-origin.

Also, even if we solve this for navigation, that still leaves all other cases open, so I don't think that makes much sense.

[jakearchibald]

if we solve this for navigation, that still leaves all other cases open

What other code-executing cases are we worried about?

[annevk]

Hmm, maybe that is the only vector. Would be good if @sirdarckcat could confirm.

Perhaps the Cache API should return a network error if the input request has redirect mode not set to "follow" and the response is the result of a redirect.

[sirdarckcat]

The PoC in http://sirdarckcat.blogspot.de/2015/05/service-workers-secure-open-redirect.html should work (it's non-HTTPS but the iframe is SSL).

I can imagine a couple other possible attacks, but they depend on how the Cache.match algorithm behaves, which IMHO is where we should fix this.

[annevk]

@sirdarckcat you keep mentioning the match algorithm, but you stop at the point of explaining how you'd fix it there. Per the model I suggested in my previous comment?

[sirdarckcat]

Sorry, I probably should stop responding on my phone :)

Yes, your solution sounds reasonable, but may not be future-proof. I think this will also become a problem:
onfetch=function(e){event.respondWith(fetch(e.request))}

And has nothing to do with Cache API, however, exploiting that would require a mechanism for me to create a cors-enabled navigational request, which AFAIK is impossible today (but might become possible in the future, one imaginary use-case could be to enable cross-origin seamless iframes, for example, although it's a strawman argument since seamless iframes are long gone crbug.com/229421)

[annevk]

You would expect that due to the presence of seamless the request would go through the parent's service worker? It's still not clear to me how you'd exploit that though. The "cors" bit would only be used to allow seamless, not share a script environment.

[annevk]

So we're going to add response.redirected that does this.

We're also going to add a check to 3.3 of HTTP fetch. See w3c/ServiceWorker#737 (comment) for details.

[wanderview]

gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1243792

[annevk]

The way the specification is written doesn't actually solve this issue as redirected would always return false for opaque responses. Surprised nobody noticed thus far, maybe we don't need this feature?

[wanderview]

We don't need the script exposed getter to return true to solve the original poster's issue. With the currently spec'd and implemented solution the linked exploit no longer works. You get a network error page because respondWith() fails due to the state of the internal redirected flag.

[annevk]

Mkay. I guess if someone feels strongly about this they should open a new issue.

[horo-t]

chromium bug: https://crbug.com/669363