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

Hi Daniel,

Is the idea that... content providers, e.g. a social media company that
provides a "latest messages" widget, would have a way to say "to use our
widget, your CSP needs to include these things".

If so, I'd normally expect to find that in their documentation (yeah, I
know, you can stop laughing now).

I'm also wondering how the "/.well-known/csp.txt" file would be used.

Craig



On Fri, 22 May 2020 at 14:38, hiburn 8 <daniel@hiburn8.org> wrote:

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