Re: Restricting <base> URLS via CSP

I'd kinda like to set "base-uri 'self'" by default, yes. That's not in the
spec strawman I put up, because I'd like to hear other opinions.

At the moment, I think the overlap between sites using base elements and
those currently using CSP is close to null. :)

-mike
On Mar 26, 2013 4:28 PM, "Ian Melven" <imelven@mozilla.com> wrote:

>
> so a user agent supporting CSP 1.1 will block (ignore) a <base> element
> when there is a CSP with no base-uri directive ?
> (ie. there's possible breakage due to non-backwards compatibility with
> existing policies for documents that may use
> <base>)
>
> i agree that #2 seems like the best option, fwiw.
>
> thanks,
> ian
>
>
> ----- Original Message -----
> From: "Mike West" <mkwst@google.com>
> To: "Alex Russell" <slightlyoff@google.com>
> Cc: "Devdatta Akhawe" <dev.akhawe@gmail.com>, public-webappsec@w3.org,
> "Michal Zalewski" <lcamtuf@google.com>, "Adam Barth" <w3c@adambarth.com>,
> justashar@gmail.com
> Sent: Tuesday, March 26, 2013 8:23:05 AM
> Subject: 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.
>
>
>