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)

Re: CSP Vasilij Schneidermann 08 Aug 2022 20:47 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/