Re: Restricting <base> URLS via CSP

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.

Received on Tuesday, 26 March 2013 15:29:12 UTC