Closed fmarier closed 1 year ago
Here's the pattern that iOS uses: https://github.com/brave/brave-ios/search?q=securityToken
@keur have you looked at this one yet?
@diracdeltas Not yet. Has no priority attached. We can put a P3
on this and I'll look into it this week?
Also might need to reach out to you or PJ to understand exactly what iOS is doing...
P3 sounds good; added
It is possible to insert arbitrary text into brave://adblock
by changing the JS context to "Brave" in the devtools and running something like:
chrome.runtime.sendMessage({type:"cosmeticFilterCreate", host:"fmarier.org", selector:"body { background-color: red; }"})
This gets applied immediately in the page and results in the following rule in brave://adblock:
fmarier.org##body { background-color: red; }
but on a page reload it fails to parse:
Uncaught DOMException: Failed to execute 'insertRule' on 'CSSStyleSheet': Failed to parse the rule 'body { background-color: red; }{display:none !important;}'.
The fact that a compromise renderer can temporarily affect the contents/looks of a page is not a new capability and so that's not something we need to fix.
I was however able to insert a rule for a different domain:
chrome.runtime.sendMessage({type:"cosmeticFilterCreate", host:"fmarier.org", selector:"#hidden-avatar"})
brave://adblock/
to see that the following rule was inserted: fmarier.org###hidden-avatar
We should derive the host ourselves from sender.origin
and remove the host
parameter in order to limit such rule injections to just the current origin.
PASSED
usingBrave | 1.50.91 Chromium: 111.0.5563.64 (Official Build) beta (x86_64) |
---|---|
Revision | c710e93d5b63b7095afe8c2c17df34408078439d-refs/branch-heads/5563@{#995} |
OS | macOS Version 11.7.4 (Build 20G1120) |
1.50.91
abcnews.com
, cnn.com
, and foxnews.com
-->
Block element`Create
brave://settings/shields/filters
Reload this page
, for each siteabcnews.com |
cnn.com |
foxnews.com |
brave://settings/shields/filters |
sites without logos |
---|---|---|---|---|
Verification passed on
Brave | 1.50.93 Chromium: 111.0.5563.64 (Official Build) beta (64-bit) |
---|---|
Revision | c710e93d5b63b7095afe8c2c17df34408078439d-refs/branch-heads/5563@{#995} |
OS | Ubuntu 18.04 LTS |
1.50.x
abcnews.com
, cnn.com
, and foxnews.com
-->
Block element`Create
brave://settings/shields/filters
Reload this page
, for each siteVerified test plan from https://github.com/brave/brave-browser/issues/16863#issuecomment-896457715
Verification PASSED
using
Brave | 1.50.108 Chromium: 112.0.5615.39 (Official Build) (64-bit)
-- | --
Revision | a0e7b9718a92bcd1cf33b7c95316caff3fc20714-refs/branch-heads/5615@{#753}
OS | Windows 11 Version 22H2 (Build 22621.1413)
1.50.91
nbcnews.com
, time.com
, and theguardian.com/us
-->
Block element`Create
brave://settings/shields/filters
Reload this page
, for each sitenbcnews.com |
time.com |
theguardian.com |
brave://settings/shields/filters |
sites without logos |
---|---|---|---|---|
The content script which implements Shields cosmetic filtering talks to the extension background script over a
postMessage
channel. This means that a compromised renderer could send messages to the extension as well.We should look into whether or not we can make use of a random token to restrict the messages accepted by the backend to those that originating from the content script injected by the extension.
Originally reported at https://hackerone.com/reports/1254125.