CSP
Jakub T. Jankiewicz
(06 Aug 2022 13:55 UTC)
|
Re: CSP
Arthur A. Gleckler
(08 Aug 2022 18:28 UTC)
|
Re: CSP
Jakub T. Jankiewicz
(08 Aug 2022 20:00 UTC)
|
Re: CSP
Arthur A. Gleckler
(08 Aug 2022 20:14 UTC)
|
Re: CSP Vasilij Schneidermann (08 Aug 2022 20:47 UTC)
|
Re: CSP
Arthur A. Gleckler
(03 Oct 2022 21:14 UTC)
|
Re: CSP
Jakub T. Jankiewicz
(19 Jan 2023 14:04 UTC)
|
Re: CSP
Magnus Ahltorp
(19 Jan 2023 19:50 UTC)
|
Re: CSP
Jakub T. Jankiewicz
(19 Jan 2023 20:10 UTC)
|
On 08/08/22 at 01:14pm, Arthur A. Gleckler wrote: > What do other people think? Having worked in security for a while, perhaps > I'm over cautious. Disclaimer: I'm far from an expert on client-side web security, but happen to work in appsec. According to the CSP3 specification §9.1 [2]_, CSP should not interfere with bookmarklets or browser add-ons in the first place. From what I've seen in the wild, add-ons have the better leverage to bypass CSP, for example by using browser-specific APIs to inject content into the website [1]. An observation I've made when testing web applications is that websites tend to fall into two camps: - No use of CSP at all. - Very permissive CSP policy with trivial XSS bypasses. It's rare to spot a website using CSP appropriately. The reason for this is simple, it's a fairly intrusive security measure that requires occasional adjustments to ensure XSS attacks are blocked, while at the same time guaranteeing the application functions correctly. The easiest way out is to use a permissive policy or none at all. Ideally, there would be no need for CSP in the first place by preventing XSS in an architectural way: - Do not embed user input into the website, ever - When embedding user input, guarantee it's encoded correctly depending on the surrounding context The former option is how the scheme.org subdomains are operating currently. The latter option is a mostly solved problem thanks to the use of s-expressions over stringly typed templating languages [5]_. There are still some contexts where it's not safe to embed user input though [6]_, these need to be avoided whenever possible. I do not have a good solution for this, other than programmer discipline. Maybe the langsec efforts [7]_ do. [1] https://stackoverflow.com/questions/7607605/does-content-security-policy-block-bookmarklets [2] https://www.w3.org/TR/CSP3/#security-considerations [3] https://bugzilla.mozilla.org/show_bug.cgi?id=866522 [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357 [5] https://www.more-magic.net/posts/structurally-fixing-injection-bugs.html [6] https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html [7] http://langsec.org/