Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sticky: unofficial: the extension csp header modification game #664

Open
Thorin-Oakenpants opened this issue Mar 13, 2019 · 27 comments

Comments

Projects
None yet
@Thorin-Oakenpants
Copy link
Member

commented Mar 13, 2019

Anyone want a game of craps?

  • required reading: #265
  • bugzillas: 1421725, 1417249 marked duplicate of 1477696, and 1462989
  • short description: when two or more extensions use CSP injection to modify headers on the same page, only one wins. It doesn't matter who: first loaded, first modified - don't care: the fact is only one extension will achieve what it is meant to, the other(s) will fail
  • FYI: The wiki page for extensions has been updated to reflect just how dangerous this is (such as JS blocking not getting blocked), but is by no means definitive

Use this sticky to report where settings use CSP: especially in our recommended extensions - outside of those, I don't really care, but it would be interesting, for example, to know that other popular extensions such as ABP or even Chameleon cause issues

⭐️ CSP header injection is used extensively in uBlock Origin, for example (see gwarser's comment four posts down). The entries below are some features you could consider disabling (or achieving another way) to reduce CSP header injection issues, depending on what extensions you use. It is up to you to determine what mix you want

template

- extension: 
- setting:
   * comment
- solution:

TIP from gwarser 💋 CRX viewer and search for !content-security-policy. (! means scan all files.) If they touch this header, they are potentially unsafe.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Mar 13, 2019

  • extension: uBlock Origin
  • setting: uncheck Dashboard>Settings>Block remote fonts
    • This sets a font rule and font rules use CSP header modification [no word from gorhill if font filters are an issue, asked twice, I guess he's busy - @gwarser then]
  • solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)
@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Mar 13, 2019

  • extension: Canvas Blocker
  • setting: Misc > Block data URL pages
  • solution: uncheck it. Not sure if RFP covers this, but it certainly causes blockage failure as seen in multiple issues raised at CB's repo
@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Mar 13, 2019

  • extension: HTTPS-Everywhere
  • setting: uncheck toolbar icon dropdown> Encrypt All Sites Eligible (EASE)
    • by default this is unchecked
  • solution: make sure any bookmarked URLs are HTTPS and disable any mixed content. Maybe use a different extension like HTTPZ - disclaimer: you will need to check any extension yourself to make sure it does not use CSP header injections
@gwarser

This comment has been minimized.

Copy link

commented Mar 13, 2019

This will not be so easy in uBO. I don't think CSP can be safely disabled without modifying uBO code. Also, disabling CSP filtering will cripple uBO a lot. uBO will need to be the one extension with CSP enabled.

Starting from here: https://github.com/gorhill/uBlock/blob/87feb47b51202cb8464eab91597b706965a224f3/src/js/traffic.js#L764

  • Inline script filtering is powered by CSP (except for HTML filtering - ##^, but this will not work for all scripts)
  • Inline fonts:
    • "Block remote fonts" feature - no-remote-fonts: example.com true. Related code: 1 (called for main_frame), 2, 3 (Not related to $font network filtering option)
    • $inline-font static filter option, but I cannot find even one in my dump of uBO compatible filters from filterlists.com
  • Any filter list can use $csp= filters, and there are lot of them. ~400 in uBO "Filter lists", over 800 total.
@tartpvule

This comment has been minimized.

Copy link

commented Mar 22, 2019

  • extension: uMatrix
  • settings:
    • Inline script blocking
    • Inline style blocking
    • "Forbid web workers"
  • solution: just be aware that these features use CSP header injection, so perhaps to reduce the possibility of conflicts, depending on your extensions and their settings, set per scope if possible?

FYI, if it is ever used by security extensions, Feature-Policy will have much of the same problems as today's CSP.

@Thorin-Oakenpants Thorin-Oakenpants changed the title unofficial sticky: lets play the csp header modification game sticky: unofficial: the extension csp header modification game Apr 2, 2019

@curiosity-seeker

This comment has been minimized.

Copy link

commented May 7, 2019

* solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)

I think you mean this one. It doesn't answer the question if font filters cause this problem as well or not, though.

@gwarser

This comment has been minimized.

Copy link

commented May 8, 2019

About "font" blocking:

CSP is used only for blocking inline fonts (base64 encoded). Inline fonts are blocked only when "No remote fonts" popup switch is used, or if specified in static filter option $inline-font. $font option block by classic web request blocking.

@curiosity-seeker

This comment has been minimized.

Copy link

commented May 8, 2019

@gwarser : Just to make this perfectly clear: $font does not use CSP, and $inline-font does not use CSP, either. Correct?

@atomGit

This comment has been minimized.

Copy link
Collaborator

commented May 8, 2019

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

@curiosity-seeker

This comment has been minimized.

Copy link

commented May 8, 2019

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

Yes, you're right. According to this wiki site $inline-font uses CSP.

@atomGit

This comment was marked as off-topic.

Copy link
Collaborator

commented May 8, 2019

WTF went wrong with github's clock

nothing, why? we posted those comments about 7 hrs. ago, honest - you know, they say people who've been abducted by aliens experience missing time

@claustromaniac

This comment was marked as off-topic.

Copy link
Contributor

commented May 8, 2019

dafuq

@Aeriem

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

Hello there,

I'm sorry for the months of silence, life found its way to catch up to me and stomp me hard.
HTTPS-Everwhere's team is now aware of the CSP issue (HTTPS-E conflicts with NoScript in Tor Browser at Safest security setting when the EASE mode is enabled #17735).
I'm hoping that since this affects TBB, Firefox's developers will see how critical this issue actually is.
Much luv' and congrats on the spring cleaning! It was so easy to get back in the privacy game thanks to your efforts on the documentation and pref cleaning, I'm baffled. Overrides also are much fewer than they used to be. :D

claustromaniac's edit: The creepy stalker is back! (you didn't think I would forget about that, did ya?)
Aeriem's edit: Oh for Pants' sake, why did it have to stick? cries in stalker Still, it's heart-warming to see you haven't forgotten me despite my long absence! ❤️

@pipboy96

This comment has been minimized.

Copy link

commented May 9, 2019

This is why there should be an official way to apply CSP and FP to web pages that's standardised, instead of current hackish way.

@Aeriem

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

I completely agree.
Hopefully this will be resolved in the near future.
Can anything be done to help?

@Aeriem

This comment was marked as off-topic.

Copy link
Contributor

commented May 9, 2019

Imma scared, did you infiltrate Mozilla's headquarters? 😱
Blink twice if you need us to exfiltrate you quickly!

I'm curious though, are you working with the devs from the Bugzilla tickets you linked? Because that'd be super cool.

@pipboy96

This comment was marked as off-topic.

Copy link

commented May 9, 2019

@Thorin-Oakenpants Um, everything's fine? Should we be scared?

@Aeriem

This comment was marked as off-topic.

Copy link
Contributor

commented May 9, 2019

Must admit I had to reread some sentences to fully get you haha!
But I'm no better with mine, so who am I to judge? 🤷

I feel like the conversation is getting a bit personal and out of the scope of this git issue, but I'd love to carry it on somewhere else (if you don't mind).
Hit me up if you want to.
Still, I'm sorry for your loss and your work is appreciated. I learned so much from this repo.

@pipboy96 Thank you again for taking the time to review this issue, and sorry for the flood. Also, Pants quirky personality is one of the reasons this repo is quite fun to read.

@crssi

This comment was marked as off-topic.

Copy link
Collaborator

commented May 9, 2019

Yeah, maybe @Thorin-Oakenpants is not aware of, but a most of times the writing is real fun to read.
Sorry for the loss.

@pipboy96

This comment was marked as off-topic.

Copy link

commented May 9, 2019

@Thorin-Oakenpants I'm sorry for your loss. May your friend rest in peace.

@atomGit

This comment was marked as off-topic.

Copy link
Collaborator

commented May 9, 2019

sorry about your loss Pants - wish i had some magic words that would help, but i never know what to say in circumstances like this

Can anything be done to help?

vote for 1421725

@atomGit

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2019

what happens if content_security_policy is contained in the manifest of an add-on, but content-security-policy isn't contained anywhere?

"content_security_policy": "default-src 'self'; connect-src ws:; style-src 'self' 'unsafe-inline'"

@gwarser

This comment has been minimized.

Copy link

commented Jun 4, 2019

This key in manifest applies only to extension https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy

Your example is bit unusual with (not encrypted) websocket and inline stylesheets.

@atomGit

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2019

ok, i understand now - Echo for Kodi is the ext. i'm referring to btw

@WellOrientedLlama

This comment has been minimized.

Copy link

commented Jun 20, 2019

Just for the record, it seems that the last add-on to be loaded by Firefox wins the race and gets its HTTP header changes through, crushing other extensions' tweaks.

So my Firefox starts with the page about:addons, and on each startup and each add-on update, I disable uMatrix and reenable it again, so it is always the last add-on to be loaded by the Fox. Then it wins against uBlock Origin's relevant features which is what I wanted.

This bug really cries for people not to install many add-ons, it sucks. And Kris Maglione's stance bah, it's okay, let's say there's nothing to do also sucks.

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ? uBO's blob: or data: filters are also affected, if I recall correctly (been a while), though I don't know how uBO translates them internally.

@Atavic

This comment has been minimized.

Copy link

commented Jun 21, 2019

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ?

Any addon race that's conflicting on the same header's modification acts the same.

@earthlng

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

Additionally I...don't think it's limited to CSP

no it's not limited to CSP but CSP is the most important one if you care about reliably blocking inline Javascript.

Shouldn't any HTTP header be affected

yes any HTTP header is affected if 2 or more addons try to modify the same header

uBO's blob: or data: filters are also affected

yes but AFAIK uBO blocks or limits those by using a CSP header

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.