search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.12k stars 332 forks source link

Header to opt out of opaque redirect #601

Open jakearchibald opened 7 years ago

jakearchibald commented 7 years ago

Something like Access-Control-Allow-Visible-Redirect: *

This would make a redirect responses visible. If the request was cross-origin, it would still have to pass existing CORS checks, and would be filtered accordingly.

annevk commented 3 years ago

Sigh. It is a security hole, for the same reason we cannot expose HttpOnly cookies same-origin to script, as already explained.

slaneyrw commented 3 years ago

Sigh. It is a security hole, for the same reason we cannot expose HttpOnly cookies same-origin to script, as already explained.

It's not a security hole for same origin requests. Cookies are a different issue, please don't conflate the two.

As I mentioned in my previous answer, the industry has worked around the problem by changing the response HttpStatus to anything other than 30x, where we can read the header.

figroc commented 2 years ago

All the workarounds are nasty. Maybe we can intoduce a new HTTP response header Location-Policy. We could expose the Location to javascript if it sets to some value.

slaneyrw commented 2 years ago

All the workarounds are nasty. Maybe we can intoduce a new HTTP response header Location-Policy. We could expose the Location to javascript if it sets to some value.

This is what was proposed above... setting the redirect flag to manual.

The problem is that those in control of this spec have a fundamental issue with this approach. To be honest, this issue is dead and buried - even if common sense prevails.

The existing implementations of fetch in the wild are impossible to polyfill, nor detect when necessary to do so. We cannot trust what the browser will do so we have to assume it won't be able to read the header and stop sending back 30x.

When standards bodies put their head in the sand, industry works around the problem, then we ignore the standards - to everyone's detriment.

annevk commented 2 years ago

No, it's not what you proposed above. It's equivalent to what OP proposed, which still would be a viable way forward I think, provided we get implementer interest.

slaneyrw commented 2 years ago

No, it's not what you proposed above. It's equivalent to what OP proposed, which still would be a viable way forward I think, provided we get implementer interest.

What a difference a single missed word can do to change the context, I should have proof read it again!.

This is what was proposed above... WHEN setting the redirect flag to manual.

However, I still stand by my assertion that the proverbial horse has already bolted. The alternate behaviour cannot be patched or polyfilled.

gschadow commented 2 years ago

This amounts to a major bug because it is impossible to implement the Digest Authentication with redirect "follow" as there is no way to increase the nc and use a new cnonce as required by Digest Authentication. So redirect fails anyway.

At least there needs to be some way to supply updated headers for the redirected call.

SampsonCrowley commented 1 year ago

Sigh. It is a security hole, for the same reason we cannot expose HttpOnly cookies same-origin to script, as already explained.

It's not a security hole for same origin requests. Cookies are a different issue, please don't conflate the two.

As I mentioned in my previous answer, the industry has worked around the problem by changing the response HttpStatus to anything other than 30x, where we can read the header.

@slaneyrw Just because you don't understand it doesn't make it not a potential threat. It does need to be opt-in, as there are a lot of redirects in the world of the web that contain sensitive tokens. your JS is not the only js just because it's same origin.

That however, doesn't mean it needs to be a required security feature that can't be opted out of and users have zero control over. and that, the complete lack of option is where the standard has completely dropped the ball

slaneyrw commented 1 year ago

@SampsonCrowley I understand this space initimately, having been building web systems for large financials for over 25 years and I take security very seriously. Please don't make assumptions. We already have plenty of "pre-flight" checks, this is just a post-flight check.

As I said, we worked around the problem by avoiding the 30x response codes. Unfortunately the landscape is getting worse with the most popular JS frameworks coalescing around fetch under the hood.