In bug 1746089 we're looking into an auth issue with source maps. This prompted me to look into source map fetching a bit. I'm filing this bug because I can't find any security checks. In particular, I think `https://sitea.com/` shouldn't be able to say its source map is at `file:///etc/passwd` or `chrome://browser/content/`. I don't know what restrictions are specced for this, but if these are CORS requests they should probably adhere to CORS headers (I guess? Might need checking with a spec, if any exists), they should send the right referrer headers (subject to the including page's referrer policy and the like), etc. etc. Julian suggests the actual fetch happens in https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/devtools/client/shared/source-map/worker.js#154 from a chrome privileged worker. Because it's system principal, I think it can do whatever it likes, and none of the relevant CORS / referrer info will be included. That seems potentially bad (as in, combined with timing attacks can probably at least determine some privacy-sensitive stuff, or worse). Now, hopefully there are security checks somewhere between there and where we determine the source map URL - but I'm not sure where that is, and some very quick searching isn't throwing it up. The source map URL for CSS is tracked on the stylesheet, and originally comes from a header or a comment in the stylesheet, but the [platform code that stores this info](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/layout/style/StyleSheet.cpp#566-581) doesn't appear to do any checking of its own. :ochameau, do you know if I'm just not finding the right place where we do do the security checks? If not, what would be involved in getting some checks in place, and passing the right principal to the code doing the fetching?
Bug 1754066 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In bug 1746089 we're looking into an auth issue with source maps. This prompted me to look into source map fetching a bit. I'm filing this bug because I can't find any security checks. In particular, I think `https://sitea.com/` shouldn't be able to say its source map is at `file:///etc/passwd` or `chrome://browser/content/`. I don't know what restrictions are specced for this, but if these are CORS requests they should probably adhere to CORS headers (I guess? Might need checking with a spec, if any exists - are source maps allowed to be on `https://siteb.com/` in this case without any CORS stuff in place?), they should send the right referrer headers (subject to the including page's referrer policy and the like), etc. etc. Julian suggests the actual fetch happens in https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/devtools/client/shared/source-map/worker.js#154 from a chrome privileged worker. Because it's system principal, I think it can do whatever it likes, and none of the relevant CORS / referrer info will be included. That seems potentially bad (as in, combined with timing attacks can probably at least determine some privacy-sensitive stuff, or worse). Now, hopefully there are security checks somewhere between there and where we determine the source map URL - but I'm not sure where that is, and some very quick searching isn't throwing it up. The source map URL for CSS is tracked on the stylesheet, and originally comes from a header or a comment in the stylesheet, but the [platform code that stores this info](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/layout/style/StyleSheet.cpp#566-581) doesn't appear to do any checking of its own. :ochameau, do you know if I'm just not finding the right place where we do do the security checks? If not, what would be involved in getting some checks in place, and passing the right principal to the code doing the fetching?