Open
Bug 1273281
Opened 9 years ago
Updated 5 months ago
Prevent extensions from changing security headers without a separate permission
Categories
(WebExtensions :: Request Handling, defect, P3)
WebExtensions
Request Handling
Tracking
(Not tracked)
REOPENED
People
(Reporter: kmag, Unassigned)
References
Details
(Whiteboard: [webRequest][design-decision-denied]triaged)
I was looking into a bug about the Black Menu for Google extension when I noticed that it contained this code:
https://gist.github.com/kmaglione/bcf500aa6748b069049e8005a230c188
This basically makes it possible for anyone to make cross-domain requests to a huge swath of Google sites, lies to Google about the origin of the requests in the process, and removes restrictions on embedding sites into frames.
Ordinary extensions should not need to change security headers like this, and they *especially* shouldn't need to make changes such as allowing "*" as an origin in CORS headers.
There may be security extensions which do need to change these kinds of headers, though, so I think we should probably allow it via a special permission of some sort, but we shouldn't make it easy for people to do this needlessly.
Reporter | ||
Comment 1•9 years ago
|
||
I guess I re-read that. It only allows cross-origin access to https://translate.google.com/translate_a/single*, and lies about the request's origin to https://accounts.google.com/ListAccounts?listPages=1&source=ChromiumBrowser&json=standard. But that only makes things very slightly better, and the other issues are still there.
Updated•9 years ago
|
Blocks: webext-port-blackmenu
Updated•9 years ago
|
Whiteboard: [webRequest] → [webRequest][design-decision-neeed]triaged
Updated•9 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Flags: needinfo?(dveditz)
Priority: -- → P3
Updated•9 years ago
|
Whiteboard: [webRequest][design-decision-neeed]triaged → [webRequest][design-decision-needed]triaged
Comment 2•9 years ago
|
||
To be discussed at Jan 10 WebExtensions triage meeting.
Agenda: https://docs.google.com/document/d/18K97o1juaHSeYEkes1iMz8AayjuVkUuIK844ErGaa-c/edit#
Updated•9 years ago
|
Flags: needinfo?(g.maone)
Comment 3•9 years ago
|
||
What we want to do is preventing extensions from relaxing security restrictions already set by "security headers".
Certainly some extensions (case in point, NoScript) might legitimately need to *tighten* existing policies, e.g. by setting CSP headers (still, this wouldn't require *modifying* or *deleting* existing ones) which is currently the best hack we've got to implement selective embedded script blocking from WebExtensions.
Anyway, in the general case, deciding what headers are fine to be touched and how (delete/modify/add) might be quite difficult, and we do need a list of these headers and a summary of their properties, no matter if we decide to completely ban "dangerous" actions or to put them behind a scary "This extension wants to change the security policies of web pages" kind of permission.
I can see :dveditz is already needinfo-ed, adding :ekr to help better understand what to call "Security headers" and for any other wisdom they could share about this issue.
Flags: needinfo?(g.maone) → needinfo?(ekr)
Comment 4•9 years ago
|
||
After some test runs on my NoScript WebExtension prototype I must retreat about my statement that it "wouldn't require *modifying* or *deleting* existing" CSP headers.
Actually, since HTTP headers are cached, when a NoScript "Allow..." command is issued, the directive used to enforce NoScript permissions needs to explicitly be edited out from whatever cached CSP header value we've got (I use a random delimiter to ensure that I don't interfere with preset policies).
So, at least for CSP, either I need a special API or I do need a permission to *edit* (not just add) CSP headers.
Comment 5•8 years ago
|
||
We're bringing this back to the WebExtensions API triage for April 4, 2017.
Giorgio, can you make the meeting tomorrow? Call in info is here: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join
Meeting agenda is here: https://docs.google.com/document/d/1V4NP4tWnjHigS2lAosCLfkU2FTcrQnoQzzXZmmB1uzk/edit#heading=h.du5ihvu5p6ro
Comment 6•8 years ago
|
||
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #5)
> We're bringing this back to the WebExtensions API triage for April 4, 2017.
>
> Giorgio, can you make the meeting tomorrow?
I should be able to attend, thank you.
Comment 7•8 years ago
|
||
I saw this bug was flagged to be carried over to the next meeting, and it has been added to the WebExtensions API triage for April 17, 2017. The agenda can be found here: https://docs.google.com/document/d/1zKqhDqXoH9vi88q4DGtOHm1hsCF8ZwLNvCrrCE5htbc/edit#
Giorgio, will you be able to attend?
Comment 8•8 years ago
|
||
My mistake -- the meeting will be on April 18, not April 17. My apologies!
Comment 9•8 years ago
|
||
Unfortunately the notes on this bug weren't updated in a timely fashion, so here's what I remember. We felt it was really hard to explain to users that an add-on was doing this in a way that would make it worthwhile. We felt there wasn't much added security on top of existing webRequest permissions. And this would break chrome compat for extensions.
As such I think we decided to say no to this, but I think we also wanted to get Kris's feedback on that.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [webRequest][design-decision-needed]triaged → [webRequest][design-decision-denied]triaged
Updated•7 years ago
|
Product: Toolkit → WebExtensions
Reporter | ||
Updated•7 years ago
|
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 10•7 years ago
|
||
In addition to our study CORSER extension (See Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1500345 ), here are some extensions that tamper with CORS headers and therefore allow some or all cross-origin requests
https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/
https://addons.mozilla.org/en-US/firefox/addon/mheadercontrol/
https://addons.mozilla.org/en-US/firefox/addon/yoursportsinhd-stream-unblock/
https://addons.mozilla.org/en-US/firefox/addon/cross-domain-cors/
https://addons.mozilla.org/en-US/firefox/addon/corser/
https://addons.mozilla.org/en-US/firefox/addon/ascribo-arxiv-annotation/
https://addons.mozilla.org/en-US/firefox/addon/content-switcher/
https://addons.mozilla.org/en-US/firefox/addon/embedyhd/
https://addons.mozilla.org/en-US/firefox/addon/access-control-allow-origin/
https://addons.mozilla.org/en-US/firefox/addon/livetvstream/
Comment 11•7 years ago
|
||
Since this bug is similar to what I wanted to discuss, I allow myself to bring here a discussion I initiated on Github - https://github.com/mozilla/addons/issues/830
My issue concerns CORS headers, but also other security headers in general.
There are some headers that cannot be modified by extensions. This includes Cache-Control, If-Modified-Since, If-None-Match. Why not extending this to sensitive security headers like CORS ones, which in our opinion, pose more security threats.
Otherwise, make it mandatory for extensions developers to request dedicated permissions before manipulating security headers. Hence for instance, in addition to the traditional "webRequest" and "webRequestBlocking" permissions, one would have to also declare "Access-Control-Allow-Origin" as a permission in order to be able to manipulate the "Access-Control-Allow-Origin" header.
This would help in 2 situations: - first you can directly identify extensions that potentially manipulate security headers (by looking at their permissions) and focus more carefully on them during review. Moreover, you can precisely warn users that extensions they install manipulate security headers such as CORS, with the consequence that this could introduce security holes in their browse
Updated•6 years ago
|
Flags: needinfo?(dveditz)
Updated•3 years ago
|
Severity: normal → S3
Comment 12•3 years ago
|
||
Luca and Tom, do we want to fold this into bug 1786919, or is it already covered by it?
Comment 13•3 years ago
|
||
(In reply to Andreas Wagner [:TheOne] [use NI] from comment #12)
Luca and Tom, do we want to fold this into bug 1786919, or is it already covered by it?
Based on what we discussed with Shane the plan is to:
- restrict changes to security headers for MV3 extensions in Bug 1786919
- keep this bug as a follow up to bring back that ability to MV3 extensions but gating it with an explicit manifest permission (and consider also requiring a separate explicit user consent, as mentioned in Bug 1787179 comment 0).
Flags: needinfo?(tomica)
Flags: needinfo?(lgreco)
Comment 14•2 years ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Flags: needinfo?(ekr)
You need to log in
before you can comment on or make changes to this bug.
Description
•