Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardening the Firefox Front End with Content Security Policies

attackanddefense.dev

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Hardening the Firefox Front End with Content Security Policies

#21

Post by allan_s »

chrismorgan wrote: post #18
theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

note that for inline style/script, as long as you're not using `style=''` or `onclick=''` , you can use `nonce=` to have a hash and to my understanding, newly added inline script will not be tolerated, allowing to have the best of both world

Re: Hardening the Firefox Front End with Content Security Policies

#22

Post by athanagor2 »

theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

Re: Hardening the Firefox Front End with Content Security Policies

#23

Post by yanis_t »

CSP is great in mitigating a whole bunch of security concerns, and it also forces some good practices (e.g. not using inline scripts).

I recently implemented a couple of tools to generate[1] and validate[2] a CSP. Would be glad if anybody tries it.

[1] https://www.csphero.com/csp-builder [2] https://www.csphero.com/csp-validator

Re: Hardening the Firefox Front End with Content Security Policies

#24

Post by davidmurdoch »

evilpie wrote: post #10
davidmurdoch wrote: post #2

Firefox really needs to fix their CSP for extensions before this kind of thing. Here is the 9 year old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 And their extension store does not permit workarounds, even though they themselves have confirmed it's a bug.

While this is definitely annoying, most of the time this can be worked around by the extension without workarounds that themself weaken security. For example I helped uBlock Origin out in 2022 when they ran into this: https://github.com/uBlockOrigin/uBlock-issues/issues/235#iss...

Thanks for this! I'll look into implementing it soon.

Re: Hardening the Firefox Front End with Content Security Policies

#25

Post by theandrewbailey »

athanagor2 wrote: post #22
theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can be limited or stopped.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

Re: Hardening the Firefox Front End with Content Security Policies

#26

Post by davidmurdoch »

gear54rus wrote: post #9
davidmurdoch wrote: post #2

Firefox really needs to fix their CSP for extensions before this kind of thing. Here is the 9 year old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 And their extension store does not permit workarounds, even though they themselves have confirmed it's a bug.

One of the possible workarounds would be to just remove the damn header before it causes any further inconvenience. I think they do allow `webRequest` API usage in the store, don't they?

We modified the CSP to inject a per user generated nonce that exempts it script from the policy.

They said this was not allowed and removed it from the extension store.

Re: Hardening the Firefox Front End with Content Security Policies

#27

Post by davidmurdoch »

gear54rus wrote: post #12
evilpie wrote: post #11

Earlier quoted context omitted.

Removing security headers like Content-Security-Policy is forbidden by the addons.mozilla.org policy. https://extensionworkshop.com/documentation/publish/add-on-p...

I don't think this is being enforced in practice, thankfully.

It is. It happened to us a few weeks ago.

Re: Hardening the Firefox Front End with Content Security Policies

#28

Post by b112 »

Do this, and then use Firefox's profiles to have weaker instances without these configs.

Why? Some sites implement then break this, sadly.

I have extremely locked down instances for banks and so on. On Linux I have an icon which lets me easily launch those extra profiles.

I also use user.js, which means I can just drop in changes, and write comments for each config line, and keep it version controlled too. Great for cloning to other devices too.

Re: Hardening the Firefox Front End with Content Security Policies

#29

Post by bryanrasmussen »

athanagor2 wrote: post #22
theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.

Re: Hardening the Firefox Front End with Content Security Policies

#30

Post by flir »

athanagor2 wrote: post #22
theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

Cross-Site Scripting. If a user injects a malicious script into the page, it doesn't get run.
Post reply on HN