Re: A modest content security proposal.

Thanks Terri,

In overall effort, creating a (sub) domain is fairly easy now (even when
that includes getting/maintaining a HTTPS certificate).

The difficulty comes in using those separate domains.

This is something the programmer will need to spend considerable time on,
whereas a sys-admin can ignore that bit (which is why I focus more on the
developer than the sys-admin).

As in, to reference an image based on a path only, I can simply use:

    <img src="/img/logo.gif" alt="Logo" />

This works on my development, testing, and live servers (no extra work,
pretty much no risk).

If I use different domains for user-uploaded and static content, then I'm
going to need to introduce variables somewhere (or some complicated
templating system); and that's for every resource, on every page, on the
whole website.

Now, to be fair, there is another thing developers should be considering
(but often don't), and that's caching.

Those resources should have a long expiry date (+1 year?), so the paths
will need some kind of processing, otherwise you won't be able to change
the resources.

In my case, and because it's quite rare for me, I've got a quick/dirty
function that helps me:

    <img src="<?= html(*timestamp_url(*'/img/logo.gif'*)*) ?>" alt="Logo" />

And that simply adds the file modification timestamp to the path:

    <img src="/img/*1563961317-*logo.gif" alt="Logo" />

Then Apache can easily re-write that:

    RewriteCond $1/$2 -f
    RewriteRule ^(.*)/*[0-9]+-*([^/]+)$ $1/$2 [L,env=immutable]

But that's getting very specific to my development practices :-)

Craig




On Tue, 23 Jul 2019 at 21:42, Oda, Terri <terri.oda@intel.com> wrote:

>
> On Tue, Jul 23, 2019 at 12:45 PM Craig Francis <craig.francis@gmail.com>
> wrote:
>
>> On Tue, 23 Jul 2019 at 08:51, Mike West <mkwst@google.com> wrote:
>> A more typical (smaller) website probably doesn't need that many paths,
>> and if they only contain static files, then you're unlikely to find a
>> redirect in there.
>>
>> I don't have fundamental objections to including some sort of path
>>> restrictions in whatever we do next. I don't think they're terribly useful
>>> as-defined in CSP3: they sincerely complicate writing a parser, and they're
>>> more or less neutered so as to not leak data about redirects.
>>>
>>
> These two paragraphs reminded me... back before CSP, I worked on a system
> to do resource confinement, and our research at the time found that many
> sysadmins were totally ok with everything being based on domains, but many
> web design folk preferred paths, because they didn't always have sufficient
> control over their hosting (or their customers didn't, or it had the
> potential for a whole lot of open tickets and communication hassles even
> when it was doable).
>
> ... Of course, since the projects where we asked these questions was a
> research project, we made a note of it and then only wrote the demo code to
> support domains because paths would have been more work and weren't really
> more likely to get us a publication. ;)  (Ah, academia!)
>
> The tools have changed since that research paper, but I *suspect* there's
> still a "friction" against subdomains.  Hosted services like github pages
> or wordpress may not have that type of flexibility, and contract designers
> may have the same problems now as they did a decade ago.  These seem like
> issues that may affect folk who would be especially interested in a sleek
> new CSP.  Not sure how we'd test the hypothesis, but I'm thinking that
> Craig is onto something here so I guess I'm +1 for supporting paths too.
>
>  Terri
>
>