New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 641750 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 634265
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Extensions forging HTTP response headers

Reported by routeh...@gmail.com, Aug 28 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce the problem:
uBlock Origin 1.9.0 has recently been updated on the Chrome Store.

https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en

It now has code implemented that forge HTTP response headers, by way of Content-Security-Policy.

https://github.com/gorhill/uBlock/commit/8586aee848703972f01c32d9def91723419da43b

What is the expected behavior?
Extensions should not be able to arbitrarily add HTTP response headers that the browser acts upon.

Websites should have a way to detect any extensions which are in use that may be modifying the HTTP response and/or HTTP response headers so they can inform the users, put up a warning, etc.

What went wrong?
Malicious extensions can follow this example and permanently decrease the security enforced by a website and allow insecure protocols to be accessed by modify the Content-Security-Policy.

Users are never informed by the browser or the site that someone may be forging the data at the time it is happening.

A very vague warning is presented by the browser when a user installs an extension like uBlock Origin, but the user is never re-prompted when the extension is updated with insecure new operations.

Did this work before? N/A 

Chrome version: 52.0.2743.116  Channel: stable
OS Version: OS X 10.11.6
Flash Version:
 
Screen Shot 2016-08-28 at 6.08.54 AM.png
135 KB View Download
Cc: jww@chromium.org
Components: Platform>Extensions
Owner: mea...@chromium.org
Status: Assigned (was: Unconfirmed)
Mustafa, can you please help to triage.

Comment 2 by vakh@chromium.org, Sep 2 2016

Cc: devlin@chromium.org
Mergedinto: 634265
Status: Duplicate (was: Assigned)
Thanks for the report. This is a duplicate of  bug 634265 , so merging into that.

Please see comments #2 and #3 at https://bugs.chromium.org/p/chromium/issues/detail?id=634265 for our rationale.

Comment 4 Deleted

Comment 5 by routeh...@gmail.com, Oct 21 2016

I'm not allowed to view ID 634265 so I apologize for commenting here.

https://hg.adblockplus.org/adblockpluschrome/rev/92bb84339f70

Adblock Plus is now injecting CSP header in to the browser and it's preventing functionality such as Worker() from working properly, when the page wants to create a Blob-based Worker.

I don't believe it makes sense to allow a browser extension to hold web page publishers hostage and decide what functionality that they are able to use.

Adblock Plus charges companies for the ability to unlock functionality like AJAX, WebSockets and now Web Workers.
Cc: jawag@chromium.org
Basically  issue 634265  just says that extensions have priority over websites, since they are (theoretically) acting on behalf of the user.  This is true, and should be maintained.  However, Adblock Plus charging to use basic web capabilities strikes me as a little questionable from a policy standpoint, rather than a technical one.  +jawag for that.

Comment 8 by mea...@chromium.org, Oct 21 2016

@routehero: Sorry that  bug 634265  was restricted, I just made it public.

Comment 9 by mea...@chromium.org, Oct 21 2016

Labels: -Restrict-View-SecurityTeam allpublic

Comment 10 by jawag@chromium.org, Oct 22 2016

FYI re: #7, Looking into it.

Sign in to add a comment