W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2013

Re: Restricting <base> URLS via CSP

From: Alex Russell <slightlyoff@google.com>
Date: Tue, 26 Mar 2013 13:56:26 +0000
Message-ID: <CANr5HFXk53OVWw6j5wkM56fU91YAQ4K4s3Cuzb5Hjr30tcMrQA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Michal Zalewski <lcamtuf@google.com>, Adam Barth <w3c@adambarth.com>, "justashar@gmail.com" <justashar@gmail.com>
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 <javascript:_e({}, 'cvml',
> '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<javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml',
>> '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<javascript:_e({}, 'cvml', 'slightlyoff@google.com');>
>> > wrote:
>>
>>>
>>> On Feb 27, 2013 7:28 PM, "Devdatta Akhawe" <dev.akhawe@gmail.com<javascript:_e({}, 'cvml', '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.
>>>
>>
>>
>
Received on Tuesday, 26 March 2013 13:56:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC