35 ms·

Hardening the Firefox Front End with Content Security Policies

185 points by evilpie 1y ago

davidmurdoch 1y ago
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 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.
- Semaphor 1y ago
  Having fewer permissions for extensions than one might want seems fairly less important to making the browser more secure…
  - joshuaissac 1y ago
    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.
    - gear54rus 1y ago
      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.
    - pessimizer 1y ago
      > It is a balance between security for the user and security for the website owner. Which in the case of browsers should always be decided for the user, rather than balanced. The browser is a user agent. It is running on the user's hardware.
  - raxxorraxor 1y ago
    In the current browser landscape I would think not. Firefox is no less secure than Chrome or Safari and both are subject to economic incentives. You could even argue these issues negatively relate to security as well.
- pama 1y ago
  Wouldn’t fixing this bug reduce security?
  - davidmurdoch 1y ago
    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.
    - pama 1y ago
      Thanks!
  - shakna 1y ago
    If you are using filter scripts, to block specific domains or script payloads, that extension can't load on a properly secured CSP page. And that page may be using CSP to protect throwing up ads... Or malware.
    - pama 1y ago
      Thanks.
- gear54rus 1y ago
  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?
  - evilpie 1y ago
    Removing security headers like Content-Security-Policy is forbidden by the addons.mozilla.org policy. https://extensionworkshop.com/documentation/publish/add-on-policies/#development-practices https://extensionworkshop.com/documentation/publish/add-on-p...
    - gear54rus 1y ago
      I don't think this is being enforced in practice, thankfully.
      - davidmurdoch 1y ago
        It is. It happened to us a few weeks ago.
        gear54rus 1y ago
        That's crazy. Did it happen to a public extension or an unlisted one?
        davidmurdoch 1y ago
        Public, with about half a million installations. I think it was noticed only because this version had a major bug that broke a bunch of websites.
  - davidmurdoch 1y ago
    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.
- evilpie 1y ago
  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#issuecomment-1344313926 https://github.com/uBlockOrigin/uBlock-issues/issues/235#iss...
  - KwanEsq 1y ago
    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 https://bugzilla.mozilla.org/show_bug.cgi?id=1411641
  - davidmurdoch 1y ago
    Thanks for this! I'll look into implementing it soon.
theandrewbailey 1y ago
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 <link>, and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
- pocketarc 1y ago
  > should be frowned upon as hard as table-based layouts I absolutely agree with you. I've been very very keen on CSP for a long time, it feels SO good to know that that vector for exploiting vulnerabilities is plugged. One thing that's very noticeable: It seems to block/break -a lot- of web extensions. Basically every error I see in Sentry is of the form of "X.js blocked" or "random script eval blocked", stuff that's all extension-related.
- chrismorgan 1y ago
  > 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.
  - allan_s 1y ago
    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
myfonj 1y ago
I am surprised there is no policy that would allow inline event handlers set in the initial payload (or stuff emitted by document.write), but neuter any done after initial render by `….setAttribute('on…', …)`. That would keep "static form" helpers still functional, but disable (malicious) runtime templating.
SebFender 1y ago
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...
- sixaddyffe2481 1y ago
  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? :)
  - SebFender 1y ago
    Professional limits...
  - h4ck_th3_pl4n3t 1y ago
    The problem with CSP is that it's fixing the effect, not the cause. It is also made in a way that it is optional (never break the web mentality), so what happens in practice is the same as with CORS: allow all, because web devs don't understand what to do, and don't have time to read the RFC. For example: try getting a web page to run that uses a web assembly binary _and_ an external JS library. Come back after 2 weeks of debugging and let me know what your experience was like, and why you eventually gave up on it.
foobar9898989 1y ago
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.
yanis_t 1y ago
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 https://www.csphero.com/csp-builder [2] https://www.csphero.com/csp-validator https://www.csphero.com/csp-validator
b112 1y ago
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.
lol768 1y ago
This is an entire class of vulnerabilities that would've never been possible with XUL, is that correct? I appreciate they had to move for other reasons but I also really don't like the idea that the DevTools and browser chrome itself now has all of the same security issues/considerations as anything else "web" does. It was bad with Electron (XSS suddenly becoming an RCE) and makes me pretty nervous here too :(
- emiliocobos 1y ago
  Xul would've had the same issues.
  - WorldMaker 1y ago
    XUL would have had worse issues because it could make arbitrary XPCOM calls to all sorts of native components and nearly the full gamut of native component issues written mostly in C/C++. XUL was in many ways always a ticking time bomb.
    - fabrice_d 1y ago
      The current frontend still has the same XPCOM privilege access from JS, so as emiliocobos said, XUL vs. HTML does not change the security boundary. It's only a different markup language.
  - sebazzz 1y ago
    It still surprises me parts of Firefox still use XUL.
CamouflagedKiwi 1y ago
I can't help but wonder if this HTML-based setup is actually more trouble than it's worth. It seems there's a very complex ecosystem in there that is hard to reason about in this way, and it's a top-level requirement for a browser to sandbox the various bits of code being executed from a web page. Obviously hard to say what those tradeoffs are worth, but I'd be a bit nervous about it. The work covered by this post is a good thing, of course!

185 points by evilpie 1y ago

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

Semaphor 1y ago
Having fewer permissions for extensions than one might want seems fairly less important to making the browser more secure…
- joshuaissac 1y ago
  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.
  - gear54rus 1y ago
    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.
  - pessimizer 1y ago
    > It is a balance between security for the user and security for the website owner. Which in the case of browsers should always be decided for the user, rather than balanced. The browser is a user agent. It is running on the user's hardware.
- raxxorraxor 1y ago
  In the current browser landscape I would think not. Firefox is no less secure than Chrome or Safari and both are subject to economic incentives. You could even argue these issues negatively relate to security as well.
pama 1y ago
Wouldn’t fixing this bug reduce security?
- davidmurdoch 1y ago
  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.
  - pama 1y ago
    Thanks!
- shakna 1y ago
  If you are using filter scripts, to block specific domains or script payloads, that extension can't load on a properly secured CSP page. And that page may be using CSP to protect throwing up ads... Or malware.
  - pama 1y ago
    Thanks.
gear54rus 1y ago
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?
- evilpie 1y ago
  Removing security headers like Content-Security-Policy is forbidden by the addons.mozilla.org policy. https://extensionworkshop.com/documentation/publish/add-on-policies/#development-practices https://extensionworkshop.com/documentation/publish/add-on-p...
  - gear54rus 1y ago
    I don't think this is being enforced in practice, thankfully.
    - davidmurdoch 1y ago
      It is. It happened to us a few weeks ago.
      - gear54rus 1y ago
        That's crazy. Did it happen to a public extension or an unlisted one?
        davidmurdoch 1y ago
        Public, with about half a million installations. I think it was noticed only because this version had a major bug that broke a bunch of websites.
- davidmurdoch 1y ago
  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.
evilpie 1y ago
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#issuecomment-1344313926 https://github.com/uBlockOrigin/uBlock-issues/issues/235#iss...
- KwanEsq 1y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1411641
- davidmurdoch 1y ago
  Thanks for this! I'll look into implementing it soon.

theandrewbailey 1y ago

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 <link>, and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

pocketarc 1y ago
> should be frowned upon as hard as table-based layouts I absolutely agree with you. I've been very very keen on CSP for a long time, it feels SO good to know that that vector for exploiting vulnerabilities is plugged. One thing that's very noticeable: It seems to block/break -a lot- of web extensions. Basically every error I see in Sentry is of the form of "X.js blocked" or "random script eval blocked", stuff that's all extension-related.
chrismorgan 1y ago
> 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.
- allan_s 1y ago
  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

myfonj 1y ago

I am surprised there is no policy that would allow inline event handlers set in the initial payload (or stuff emitted by document.write), but neuter any done after initial render by `….setAttribute('on…', …)`. That would keep "static form" helpers still functional, but disable (malicious) runtime templating.

SebFender 1y ago

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

sixaddyffe2481 1y ago
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? :)
- SebFender 1y ago
  Professional limits...
- h4ck_th3_pl4n3t 1y ago
  The problem with CSP is that it's fixing the effect, not the cause. It is also made in a way that it is optional (never break the web mentality), so what happens in practice is the same as with CORS: allow all, because web devs don't understand what to do, and don't have time to read the RFC. For example: try getting a web page to run that uses a web assembly binary _and_ an external JS library. Come back after 2 weeks of debugging and let me know what your experience was like, and why you eventually gave up on it.

foobar9898989 1y ago

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.

yanis_t 1y ago

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 https://www.csphero.com/csp-builder [2] https://www.csphero.com/csp-validator https://www.csphero.com/csp-validator

b112 1y ago

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.

lol768 1y ago

This is an entire class of vulnerabilities that would've never been possible with XUL, is that correct? I appreciate they had to move for other reasons but I also really don't like the idea that the DevTools and browser chrome itself now has all of the same security issues/considerations as anything else "web" does. It was bad with Electron (XSS suddenly becoming an RCE) and makes me pretty nervous here too :(

emiliocobos 1y ago
Xul would've had the same issues.
- WorldMaker 1y ago
  XUL would have had worse issues because it could make arbitrary XPCOM calls to all sorts of native components and nearly the full gamut of native component issues written mostly in C/C++. XUL was in many ways always a ticking time bomb.
  - fabrice_d 1y ago
    The current frontend still has the same XPCOM privilege access from JS, so as emiliocobos said, XUL vs. HTML does not change the security boundary. It's only a different markup language.
- sebazzz 1y ago
  It still surprises me parts of Firefox still use XUL.

CamouflagedKiwi 1y ago

I can't help but wonder if this HTML-based setup is actually more trouble than it's worth. It seems there's a very complex ecosystem in there that is hard to reason about in this way, and it's a top-level requirement for a browser to sandbox the various bits of code being executed from a web page. Obviously hard to say what those tradeoffs are worth, but I'd be a bit nervous about it. The work covered by this post is a good thing, of course!