Closed Bug 1447571 Opened 7 years ago Closed 7 years ago

Cookies should not be available in webRequest without the cookie permission

Categories

(WebExtensions :: Request Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: andrew.wakeling, Unassigned)

Details

(Keywords: sec-moderate)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce: Specify a host (e.g. "*://*.example.com/*") in permissions. Add "webRequest" and "webRequestBlocking" permissions. Set up an onBeforeSenderHeaders handler for <all_urls> with 'blocking' and 'requestHeaders'. Verify that you're able to see all cookies, including HTTP & secure. A demo webextension has also been created here: https://github.com/andrewwakeling/webextension-cookie-via-webrequest Actual results: The documentation on https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions#Host_permissions is misleading and/or the behavior is undesirable. The documentation states: "the ability to access cookies for that host using the cookies API, as long as the "cookies" API permission is also included." Expected results: I believe that webRequest should limit interaction/retrieval of all (or secure) cookies, which should be explicitly controlled via the "cookies" permission. There are currently a lot of extensions which will actually ask for <all_urls> host permissions (along with webRequest permissions). This means that the extension has the ability to peek at all cookies across all sites you visit. Given that secure/http cookies are currently the best practice to store tokens for authentication, this is a huge security risk.
This is expected. If you have access to the webRequest API, you get access to everything that entails, including cookies that are part of the request. The cookies permission applies to the cookies API, which may have some overlapping functionality, but is otherwise unrelated. The same sort of overlap applies to non-http-only cookies, which can be accessed by content scripts regardless of what additional permissions they have.
Group: toolkit-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #1) > This is expected. If you have access to the webRequest API, you get access > to everything that entails, including cookies that are part of the request. > The cookies permission applies to the cookies API, which may have some > overlapping functionality, but is otherwise unrelated. The same sort of > overlap applies to non-http-only cookies, which can be accessed by content > scripts regardless of what additional permissions they have. In my mind, there's 4 things: - functionality of the browser that WebExtensions naturally wants to extend or use (e.g. Executing a script, modifying/blocking a network request) - WebExtension permissions (in the manifest.json) - user's expectation that a WebExtension only asks for the permission it really needs/uses - messaging/communication about permissions a WebExtension requires, (during installation or when inspecting it) Right now, there's a huge misalignment between these things. I can appreciate that it's not so simple and there is overlap. My issue is that there are patterns or best practices that help ensure some level of security. (e.g. Storing sensitive cookies with httpOnly). There's not enough flexibility in the WebExtension API to protect this sensitive information. Users are dangerously asked to grant permissions that are powerful and broad. WebExtensions that require httpOnly cookie access should ask for it explicitly. This shouldn't be something that's lumped into another permission or given incidentally. Understandably, this general approach makes things slightly more complicated (e.g. A 'httpOnly' permission might have to address 'Set-Cookie' headers too). In the meantime, there should be better transparency and documentation which explicitly addresses how some permissions (or mechanics) may incidentally get granted. e.g. the permission is called 'cookies' but it's really 'cookiesApi' because interaction with non-httpOnly cookies is possible via scripting (e.g. executeScript), or via webRequests (as stated in this issue). Lastly, there needs to be more pressure put on browsers to communicate how powerful these permissions are. There's an overwhelming number of extensions that simply ask for <all_urls> because it's easy. Without fear mongering, users should be honestly told that some extensions have the capability to steal passwords or impersonate you on other sites. Something needs to happen. The current situation is so far from ideal and currently relies on the good morality & honestly of WebExtension authors. If recent events are indicative of anything, it's something that should be addressed immediately.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.