Prevent extensions from changing security headers without a separate permission

NEW
Unassigned
(Needinfo from 2 people)

Status

()

Toolkit
WebExtensions: Request Handling
P3
normal
11 months ago
6 days ago

People

(Reporter: kmag, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webRequest][design-decision-needed]triaged)

(Reporter)

Description

11 months ago
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

11 months 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

11 months ago
Blocks: 1253374

Updated

11 months ago
Whiteboard: [webRequest] → [webRequest][design-decision-neeed]triaged

Updated

6 months ago
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Flags: needinfo?(dveditz)
Priority: -- → P3

Updated

5 months ago
Whiteboard: [webRequest][design-decision-neeed]triaged → [webRequest][design-decision-needed]triaged
To be discussed at Jan 10 WebExtensions triage meeting. 

Agenda: https://docs.google.com/document/d/18K97o1juaHSeYEkes1iMz8AayjuVkUuIK844ErGaa-c/edit#
Flags: needinfo?(g.maone)

Comment 3

3 months 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

3 months 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.
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

20 days 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.
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?
My mistake -- the meeting will be on April 18, not April 17. My apologies!
You need to log in before you can comment on or make changes to this bug.