Re: Thoughts on a 'csp.txt' Wellknown suffix

Couple typos here (it was 5am).
The only important one is the second example, which should be:
#2

   1. Path: /fonts
   2. Content-Security-Policy: font-src example.com;
   3. Path: /scripts
   4. Content-Security-Policy: script-src example.com; connect-src
   example.com;
   5. Path: iframe.example.com
   6. Content-Security-Policy: frame-src *iframe.example.com
   <http://iframe.example.com>;*


On Fri, May 22, 2020 at 5:04 AM hiburn 8 <daniel@hiburn8.org> wrote:

> Hi All,
>
> First post here so go easy on me :)
> I proposed a 'csp.txt' Wellknown suffix to ietf.org and was hoping to get
> this group's thoughts/concerns.
>
> The concept is simply that a plaintext 'csp.txt' file would describe the
> Content-Security-Policy (CSP)
> directives/values required for other origins to embed its content. This
> can optionally articulate those values
> on a per-path or per-subdomain basis.
>
> Some examples:
> #1
>
>    1. Content-Security-Policy: font-src example.com; connect-src
>    example.com
>
> #2
>
>    1. Path: /fonts
>    2. Content-Security-Policy: font-src example.com;
>    3. Path: /scripts
>    4. Content-Security-Policy: script-src example.com; connect-src
>    example.com
>    5. Path: iframe.example.com
>    6. Content-Security-Policy: frame-src example
>
>
> While i do appreciate that some people might instinctively think that this
> isn't necessary, I would argue this will provide
> a few key benefits.
>
> 1/ We all know that appsec engineers are struggling to implement the
> minimum (most secure) CSP changes required to embed
> content.
> This happens because investigating exactly what to whitelist can be time
> consuming and technically challenging, and
> because content providers do not often articulate what needs to change in
> a CSP to support them. My hope is that if we
> start expecting csp.txt files from content providers then we will get
> them, relieve ourselves of replicating the same CSP
> investigations that a hundred others, and be more secure.
>
> 2/ It may help towards a more standardised approach for hosting content.
> For example, I've seen that several content sites might host scripts on
> s.example.com or have a tracking pixel on t.example.com.
> This is great for CSP, as you can lock down the exact directives you need
> for the subdomains which need them; and you can ignore
> any you don't need. I see a lot of sites which seem to have no rhyme or
> reason to how they lay out their content, and it's infuriating.
> Particularly when they host their content on the same domain as their
> website, which has its own locally hosted Angular
> (CSP bypass anyone?).
>
> 3/ Often, half the domains in large CSPs look like gibberish as they are
> dynamically loaded JS files. It's difficult, at a glance,
> to attribute these domains to their parents (where we actually wanted to
> get content from); which makes it tricky for appsec engineers
> to understand the risks associated with each content provider.
>
> 4/ Many providers like to arbitrarily change the domains for
> dynamically loaded content, assuming that everything will work because
> their users/customers have the root script URI. When this happens, we
> don't know if they have been hacked or just too lazy to explain
> that they have changed some URLs. Now we can check a simple file.
>
> Possibly a few tenuous arguments there, but generally I think it's an ok
> idea. Yes? No?
>
> - Daniel Reece
>
>
>