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

51–60 of 71 posts

Re: Hardening the Firefox Front End with Content Security Policies

#51

Post by pessimizer »

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.

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

Re: Hardening the Firefox Front End with Content Security Policies

#52

Post by sebazzz »

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.

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

At our place we do abide by those rules, but we also use 3rd party components like Telerik/Kendo which require both unsafe-inline for scripting and styling. Sometimes you have no choice laxing your security policy.

Re: Hardening the Firefox Front End with Content Security Policies

#53

Post by sebazzz »

emiliocobos wrote: post #34
lol768 wrote: post #33

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

Xul would've had the same issues.

It still surprises me parts of Firefox still use XUL.

Re: Hardening the Firefox Front End with Content Security Policies

#54

Post by pama »

davidmurdoch wrote: post #16
pama wrote: post #4

Earlier quoted context omitted.

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.

Thanks!

Re: Hardening the Firefox Front End with Content Security Policies

#55

Post by pama »

shakna wrote: post #6
pama wrote: post #4

Earlier quoted context omitted.

Wouldn’t fixing this bug reduce security?

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.

Thanks.

Re: Hardening the Firefox Front End with Content Security Policies

#56

Post by allan_s »

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

forbidding inline script protect you from

``` hello $user ```

with $user being equal to `/* sending your session cookie out, or the value of the tag #credit-card etc. */`

you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably found was

` {{ 'hello dear $user' | translate | unsafe }}` with unsafe deactivating the auto-escape because people wanted the feature to be released, and thinking of a way to translate the string intermixed with html was too time-consuming

for inline style, it may hide elements that may let you input sensitive value in the wrong field , load background image (that will 'ping' a recipient host)

with CSP activated, the vulnerability may exists, but the javascript/style will not be executed/applied so it's a safety net to cover the 0.01 case of "somebody has found an exploit in

Re: Hardening the Firefox Front End with Content Security Policies

#57

Post by diggan »

allan_s wrote: post #56
athanagor2 wrote: post #22

Earlier quoted context omitted.

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

forbidding inline script protect you from ``` hello $user ``` with $user being equal to ` /* sending your session cookie out, or the value of the tag #credit-card etc. */ ` you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably fou…

> forbidding inline script protect you from

What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content. Most popular frameworks/libraries handle that as securely by default as one could (including React) and only when you use specific ways (like React's dangerouslySetInnerHTML or whatever it is called today) are you actually opening yourself up to a hole like that.

If you cannot rely on the escaping of whatever templating engine/library you're using, you're using someone's toy templating library and probably should switch to a proper one that you can trust, ideally after actually reviewing it lives up to whatever expectation you have.

> ` {{ 'hello dear $user' | translate | unsafe }}`

This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript.

I do agree with your last part that CSP does help slightly with "defense in depth", for when you do end up with vulnerabilities.

Re: Hardening the Firefox Front End with Content Security Policies

#58

Post by diggan »

bryanrasmussen wrote: post #29
athanagor2 wrote: post #22

Earlier quoted context omitted.

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.

> 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

Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical tag.

In short, CORS applies to network requests made by scripts, not to the scripts themselves

Re: Hardening the Firefox Front End with Content Security Policies

#59

Post by bryanrasmussen »

diggan wrote: post #58
bryanrasmussen wrote: post #29

Earlier quoted context omitted.

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.

> 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 Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical tag. In short…

ah yeah, sorry wasn't thinking clearly.

Re: Hardening the Firefox Front End with Content Security Policies

#60

Post by CamouflagedKiwi »

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!

Post reply on HN