Just adding one note, because I was testing new version of my Scheme REPL
bookmark. Google, YouTube and Wikipedia allow to run my bookmark without any
issues. But it doesn't work on scheme.org or github.com. From my understanding
such strict CSP is added only when people don't understand how this system
works and just disable everything they can even when don't needed to. Or when
thet are afraid for no reason or don't trust they code. And what they do is
that they restrict what tools can do (bookmarks).

YouTube and Wikipedia are good examples they don't need such strict CSP even
that they accept user input. Wikipedia (Media Wiki) even allows limited amount
of HTML in articles and it's fine, no one hacked Wikipedia.

On Mon, 8 Aug 2022 22:47:41 +0200
Vasilij Schneidermann <xxxxxx@vasilij.de> wrote:

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

--
Jakub T. Jankiewicz, Senior Front-End Developer
https://jcubic.pl/me