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

61–70 of 71 posts

Re: Hardening the Firefox Front End with Content Security Policies

#61

Post by midtake »

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.

Why? If you're the content owner, you should be able to. If you factor out inline code, you will likely just trust your own other domain. When everything is a cdn this can lead to less security not more.

Do you mean people should be banned from inlining Google Analytics or Meta Pixel or Index Now or whatever, which makes a bunch of XHRs to who knows where? Absolutely!

But nerfing your own page performance just to make everything CSP-compliant is a fool's errand.

Re: Hardening the Firefox Front End with Content Security Policies

#62

Post by LegionMammal978 »

SahAssar wrote: post #47
LegionMammal978 wrote: post #43

Earlier quoted context omitted.

It does seem like CSP nonces do not play well with caching (since they must have a different value on each page load), which would make them a detriment to performance.

You can also include a hash of the contents in the CSP, which plays well with caching.

True, a hash works as a good alternative. (Unless you're doing super weird stuff like generating inline scripts at runtime.)

Re: Hardening the Firefox Front End with Content Security Policies

#63

Post by fabrice_d »

WorldMaker wrote: post #38
emiliocobos wrote: post #34

Earlier quoted context omitted.

Xul would've had the same issues.

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.

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.

Re: Hardening the Firefox Front End with Content Security Policies

#64

Post by SebFender »

sixaddyffe2481 wrote: post #19
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? :)

Professional limits...

Re: Hardening the Firefox Front End with Content Security Policies

#65

Post by thayne »

theandrewbailey wrote: post #40
chrismorgan wrote: post #18

Earlier quoted context omitted.

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

It's called Content Security Policy, not Content Performance Policy. My thoughts: 1. Inlining everything burns bandwidth, even if it's 100KB each. (I hope your cloud hosting bills are small.) External resources can be cached across multiple pageloads. 2. Best practice is to load CSS files as early as possible in the header, and load (and defer) all scripts at the end of the page. The browser can request the CSS befor…

> It's called Content Security Policy, not Content Performance Policy

As is often the case with security, the downsides of locking something down may not be worth the increased security .

Another reason not to prohibit inline scripts and stylesheets is if you need to dynamically generate them (although I think strict-dynamic would allow that).

> External resources can be cached across multiple pageloads.

That only matters if the resource is actually shared across multiple pages

Re: Hardening the Firefox Front End with Content Security Policies

#66

Post by h4ck_th3_pl4n3t »

sixaddyffe2481 wrote: post #19
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? :)

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.

Re: Hardening the Firefox Front End with Content Security Policies

#67

Post by raxxorraxor »

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…

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.

Re: Hardening the Firefox Front End with Content Security Policies

#68

Post by raxxorraxor »

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…

What is the security difference of someone injecting something into your page vs injecting something into external ressource?

Re: Hardening the Firefox Front End with Content Security Policies

#69

Post by wizzwizz4 »

bgirard wrote: post #42
chrismorgan wrote: post #18

Earlier quoted context omitted.

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

> 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 Do you have data to back this up? What are you basing this statement on? My intuition agrees with you for the reasons you state but when I tested this in production, my workplace found the breakeven point to be at around 1KB surprisingly. Un…

I would expect it to be closer to 1KB, as well. 100KB is (at time of writing) about 5× the size of this webpage, and this doesn't load instantly for me.

Re: Hardening the Firefox Front End with Content Security Policies

#70

Post by allan_s »

diggan wrote: post #57
allan_s wrote: post #56

Earlier quoted context omitted.

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 openi…

my point is that all your templates are at thend coded by human that make mistakes https://nvd.nist.gov/vuln/detail/CVE-2024-6578 , you may be not using "dangerouslySetInnerHTML" directly but your dependencies may

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

I fail to understand your point (it's certainly an understanding problem on my side)

What I wanted to express is that: 1. you can with some CSP forbid loading of cross origin script (i.e forbid hacker.ru/toto.js ) to be loaded 2. but even if you do this, you also want to block inline script (or use inline+nonce) because evil script can be executed from within your origin by using a vulnerability somehwere between the code and the final dom

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

yes we both agree that it's the same vulnerability at the end, i'm just saying that you can arrive there from different path, and these different path are protected by different CSP mechanism

Post reply on HN