←back to thread

Hardening the Firefox Front End with Content Security Policies

(attackanddefense.dev)
182 points evilpie | 1 comments | 09 Apr 25 09:34 UTC | HN request time: 1.161s | source
Show context
lol768 ◴[09 Apr 25 12:59 UTC] No.43631552[source]▶
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 :(

replies(1): >>43631677 #
emiliocobos ◴[09 Apr 25 13:12 UTC] No.43631677[source]▶
Xul would've had the same issues.
replies(2): >>43632263 #>>43633749 #
WorldMaker ◴[09 Apr 25 14:03 UTC] No.43632263[source]▶
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.

replies(1): >>43639122 #
1. fabrice_d ◴[09 Apr 25 23:33 UTC] No.43639122[source]▶
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.