Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should fetches to blob URLs be more restricted? #666

Open
mkruisselbrink opened this issue Jan 31, 2018 · 7 comments
Open

Should fetches to blob URLs be more restricted? #666

mkruisselbrink opened this issue Jan 31, 2018 · 7 comments

Comments

@mkruisselbrink
Copy link
Collaborator

If I'm reading the spec correctly, currently the spec allows both no-cors and navigate requests to cross-origin blob URLs. I don't think that is actually what implementations do. I haven't done exhaustive testing, but at least chrome and firefox both seem to block cross origin navigate requests to blob URLs and at least some no-cors requests.

So am I missing something in the spec, or is the spec actually more permissive than what implementations do?

@annevk
Copy link
Member

annevk commented Jan 31, 2018

I think it might be more permissive. It's a little bit unclear to me why implementations have this difference, though I can see it making sense for process boundaries. Happy to lock this down more. Are you interested in helping with tests by any chance?

@mkruisselbrink
Copy link
Collaborator Author

I've been trying to write tests, yes. And the situation (at least in chrome) is fairly complicated. What I've figured out so far:

  • Chrome does block no-cors fetches to blob: URLs in img tags etc, but does not block no-cors fetches via the fetch API (but of course then you can't do much with those opaque responses, since using those responses still ends up getting blocked). Firefox blocks all no-cors requests I've been able to come up with so far.

  • For navigate requests it's also complicated. Chrome blocks most of these requests, except for noopener window.open. In that case chrome does seem to let the request go through. And I'm sure there's plenty of permutations of variables I haven't tried yet, so I'm not sure what exactly Chrome currently does or doesn't block...

I'll work on cleaning up my tests a bit more and trying to add more cases/see what other browsers are doing.

@wanderview
Copy link
Member

In a world where we have moved data URLs to opaque origins, do we want to open up cross-origin blob URLs?

@mkruisselbrink
Copy link
Collaborator Author

In a world where we have moved data URLs to opaque origins, do we want to open up cross-origin blob URLs?

I don't think so, no. I would be greatly in favor of restricting all cross-origin blob URL loading (which matches what Firefox already seems to be doing). I'm not even sure if the few cases where Chrome doesn't block them are intentional or just bugs/oversights.

@wanderview
Copy link
Member

Ok, good.

I don't know if its a problem, but the cross-origin blob URLs also kind of leak some information about when the creating context goes away. If thats like a nested context that the current origin wouldn't know about it might be some kind of cross-origin information leakage. Kind of weak, but nice to avoid.

@mkruisselbrink
Copy link
Collaborator Author

Started writing some tests in web-platform-tests/wpt#9320. Somewhat interesting, firefox actually throws when trying to navigate to a cross origin blob: URL, which is not the behavior you'd get if fetch would just return a network error.

@annevk
Copy link
Member

annevk commented Feb 1, 2018

I think that's a bug in Firefox that can hopefully be fixed. All URLs should have an identical "API".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants