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

Re: Restricting <base> URLS via CSP

From: Ian Melven <imelven@mozilla.com>
Date: Tue, 26 Mar 2013 10:22:30 -0700 (PDT)
To: Mike West <mkwst@google.com>
Cc: Ashar Javed <justashar@gmail.com>, Michal Zalewski <lcamtuf@google.com>, Alex Russell <slightlyoff@google.com>, public-webappsec@w3.org, Adam Barth <w3c@adambarth.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Daniel Veditz <dveditz@mozilla.com>
Message-ID: <2030981541.5262781.1364318550009.JavaMail.root@mozilla.com>


----- Original Message -----
From: "Mike West" <mkwst@google.com>
To: "Ian Melven" <imelven@mozilla.com>
Cc: "Ashar Javed" <justashar@gmail.com>, "Michal Zalewski" <lcamtuf@google.com>, "Alex Russell" <slightlyoff@google.com>, public-webappsec@w3.org, "Adam Barth" <w3c@adambarth.com>, "Devdatta Akhawe" <dev.akhawe@gmail.com>
Sent: Tuesday, March 26, 2013 8:54:09 AM
Subject: 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 first thought that seems like a reasonable approach, i'm also curious if there's other opinions here. dveditz ?

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

i am willing to believe that ;) should be another round of interesting data on sites using security headers later today,
I'm told.

cheers,
ian

 
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. 
Received on Tuesday, 26 March 2013 17:23:01 UTC

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