Re: Restricting <base> URLS via CSP

hi Alex

I think thats a great idea! Can you share with us what attacks and how
they are remediated by controlling base urls? There have been a couple
of discussions about post-xss attacks.

I personally prefer sensible defaults over opt-in. For example,
script-src defaults to blocking inline scripts. Users have to opt-out
to enable inline scripts and eval.

I wonder if we can consider defaulting to "Base URL can only be same
origin" or "base URL is ignored" as soon as we see a script-src in the
CSP policy?

This might be a little ugly, but I think there is a possibility of
harm if we don't default to "Turn on CSP script-src and it will take
care of most problems." In the future, we don't want to see "yeah X %
of webapps turn on CSP but forgot to specify the base-uri directive"

Is there is a way to measure how many applications turn on CSP but
also need to specify a cross-origin base-uri ? I can't actually think
of a case where this is needed, but I am inexperienced in these
matters.


--dev



On 27 February 2013 15:57, Adam Barth <w3c@adambarth.com> wrote:
> Moving to public-webappsec (which is the working group for CSP as
> opposed to the general Security Interest Group).
>
> Adam
>
>
> On Wed, Feb 27, 2013 at 3:53 PM, Alex Russell <slightlyoff@google.com> wrote:
>> Hi all,
>>
>> After chatting with Adam and Mike, I'd like to propose a new CSP field for
>> setting a restriction on the base URL of a document. Having this provided in
>> a header and/or early in the page provides a bulwark against many of the
>> worst post-CSS HTML injection attacks, and when combined with existing CSP
>> 1.1 directives can deny many of the worst payload smuggling attacks.
>>
>> Is there appetite in the group to specify this for 1.1?
>>
>> Regards
>

Received on Thursday, 28 February 2013 00:21:17 UTC