Re: Restricting <base> URLS via CSP

I've landed a very rough strawman of this functionality in
http://trac.webkit.org/changeset/146886. Should be in a Canary later this
week (locked safely behind the "Experimental WebKit Features" flag, of
course) for experimentation.

I think I agree with you, Alex. #2 seems like the best and most consistent
option. #3 probably isn't worth doing.

-mike

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Tue, Mar 26, 2013 at 2:56 PM, Alex Russell <slightlyoff@google.com>wrote:

> On Monday, March 25, 2013, Mike West wrote:
>
>> In the hopes of sparking conversation, I've strawmanned up a first pass
>> at this: https://dvcs.w3.org/hg/content-security-policy/rev/4b89c246ea16.
>>
>> I see three ways of approaching this:
>>
>> 1. 'base-uri [URI]' actually set the document's base URL. After
>> consideration, I don't think this is a good idea; it seems surprising.
>>
>> 2. 'base-uri [source-list]' sets a set of URIs which are acceptable base
>> URLs for the document. A <base> element would still be required in order to
>> change the document's base URL. That is what the commit above implements.
>>
>
> This was my assumption about how this would work.
>
>
>>  3. We add some mechanism of explicitly saying "the base URL can't be
>> changed". Perhaps 'lock-base-uri' directive, or a more generic
>> 'page-options' directive with a 'lock-base-uri' value?
>>
>
> I dislike this because it means that in a first-wins <base> case (har har)
> with an HTML injection vuln in the head, you can still be hosed. This seems
> both dangerous and misleading.
>
>
>> #2 seems to me to be most clearly in line with what we're currently doing
>> in CSP directives; I'd love other opinions. :)
>>
>> -mike
>>
>> --
>> Mike West <mkwst@google.com>, Developer Advocate
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>
>>
>> On Mon, Mar 18, 2013 at 12:15 PM, Mike West <mkwst@google.com> wrote:
>>
>>> Thanks for the suggestion, both Alex and Ashar.
>>>
>>> I agree that there's some value in a directive like this one, but it's
>>> unclear to me how it should work. In particular:
>>>
>>> * '*-src' directives set a list of accepted sources, while 'sandbox'
>>> actually changes a flag on the document. How should base restrictions be
>>> handled? Should 'base-uri http://example.com/' set the protected
>>> resource's base URL, or should it allow the page to set its base URL to '
>>> http://example.com/' if it chooses?
>>>
>>> * I'm sympathetic to setting something like "base-url 'self'" by default
>>> whenever a policy is active. I suspect that would have little to no impact
>>> on the web at large, and would kill an attack vector. I'll see what I can
>>> find out about <base> usage in general; in the absence of data, are there
>>> objections to this? It's not exactly consistent with some other decisions
>>> we've made (allowing unlisted items by default, for instance)... if
>>> "whenever a policy is active" is unappealing, would "whenever any
>>> non-sandbox directive is enforced" be better (as I vaguely recall that
>>> being the sticking point)?
>>>
>>> --
>>> Mike West <mkwst@google.com>, Developer Advocate
>>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>>
>>>
>>> On Fri, Mar 1, 2013 at 7:03 PM, Alex Russell <slightlyoff@google.com>wrote:
>>>
>>>>
>>>> On Feb 27, 2013 7:28 PM, "Devdatta Akhawe" <dev.akhawe@gmail.com>
>>>> wrote:
>>>> >
>>>> > > This isn't just about scripts; it affects forms, images, and every
>>>> other
>>>> > > sort of network behavior.
>>>> >
>>>> > My point was that web application authors opt-in to XSS protection
>>>> > only when they specify a script-src. In the absence of script-src, we
>>>> > are in XSS world, not post-xss.
>>>>
>>>> Ah, yes. Apologies for getting your meaning the first time.
>>>>
>>>
>>>
>>