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.
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 :(
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.
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
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!
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.
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...
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.
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.