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

11–20 of 71 posts

Re: Hardening the Firefox Front End with Content Security Policies

#11

Post by evilpie »

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?

Removing security headers like Content-Security-Policy is forbidden by the addons.mozilla.org policy.

https://extensionworkshop.com/documentation/publish/add-on-p...

Re: Hardening the Firefox Front End with Content Security Policies

#12

Post by gear54rus »

evilpie wrote: post #11
gear54rus wrote: post #9

Earlier quoted context omitted.

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?

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.

Re: Hardening the Firefox Front End with Content Security Policies

#14

Post by joshuaissac »

Semaphor wrote: post #3
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.

Having fewer permissions for extensions than one might want seems fairly less important to making the browser more secure…

Arguably, it can make it less secure by reducing the user's control over what content the browser loads or what scripts it executes. For example, users may be using extensions to selectively replace harmful content (like intrusive JavaScript, tracking) with benign content. It is a balance between security for the user and security for the website owner.

Re: Hardening the Firefox Front End with Content Security Policies

#15

Post by foobar9898989 »

Mozilla's finally realizing what my paranoid uncle has been shouting for years: "They're coming for your browser UI!"Jokes aside, it's pretty cool seeing them implement CSP in the front-end. Kind of like putting a security guard at the entrance of a bank that already has 50 guards inside. But hey, that 51st guard might be the one who catches the bad guy!The separation between privileged and unprivileged processes reminds me of my relationship with coffee - I know I shouldn't let it access my system too often, but somehow it always finds a way in.What's actually impressive is how Firefox keeps evolving despite being around forever (in internet years). Most of us would have given up and said "eh, good enough" years ago. Next thing you know they'll be securing the about:config page with a pop quiz on quantum physics.

Re: Hardening the Firefox Front End with Content Security Policies

#16

Post by davidmurdoch »

pama wrote: post #4
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.

Wouldn’t fixing this bug reduce security?

No, it's explained more in the issue. An extension is a part of the "User Agent". The CSP header in FF is almost seemingly arbitrarily applied to extensions.

Re: Hardening the Firefox Front End with Content Security Policies

#17

Post by KwanEsq »

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...

And it's worth noting that since your comment later in that thread about sandbox being an issue, that's been fixed too as of Firefox 128: https://bugzilla.mozilla.org/show_bug.cgi?id=1411641

Re: Hardening the Firefox Front End with Content Security Policies

#18

Post by chrismorgan »

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 with only inline styles and scripts. The threshold where it becomes more subjective is, for most target audiences, possibly over half a megabyte by now.

Seriously, it’s ridiculous just how good inlining everything is for performance, whether for first or subsequent page load; especially when you have hundreds of milliseconds of latency to the server, but even when you’re nearby. Local caches can be bafflingly slow, and letting the browser just execute it all in one go without even needing to look for a file has huge benefits.

It’s also a lot more robust. Fetching external resources is much more fragile than people tend to imagine.

Re: Hardening the Firefox Front End with Content Security Policies

#19

Post by sixaddyffe2481 »

SebFender wrote: post #13

CSP is a soothing cream but is most usually easily bypassed by other simple attacks relying on poor DOM management and security - to this day my team has never found so many web vulnerabilities just going into the DOM...

Their blog has a lot of posts on trying to attack Firefox. If it's so simple, why are you not in the bug bounty hall of fame? :)

Re: Hardening the Firefox Front End with Content Security Policies

#20

Post by gear54rus »

joshuaissac wrote: post #14
Semaphor wrote: post #3

Earlier quoted context omitted.

Having fewer permissions for extensions than one might want seems fairly less important to making the browser more secure…

Arguably, it can make it less secure by reducing the user's control over what content the browser loads or what scripts it executes. For example, users may be using extensions to selectively replace harmful content (like intrusive JavaScript, tracking) with benign content. It is a balance between security for the user and security for the website owner.

Exactly. It's been clearly established that web extensions' code is more priveleged than a page code, as it should be. The amount of people going 'muh sesoority' in this thread is baffling.
Post reply on HN