RE: [W3C Web Security IG] capability URLs

Hi Michal,

Thanks for your comments on the capability URLs spec. I have updated it in line with several of them, and added issues where more work is needed. The modified version is at:

  http://w3ctag.github.io/capability-urls/

and you can see the changes here:

  https://github.com/w3ctag/capability-urls/commit/81a6aea41397ccc378b2e0a0395fb36151b4259a

To be clear, this is intended for publication as a TAG Finding (equivalent to a Note) to attempt to pull together expert advice on best practices in using capability URLs. There are no normative requirements in the document; it’s aim is to be helpful for web developers. I’ve tried to make that clearer in the "Status of this Document”.

The document is going through the W3C Working Draft process precisely to integrate input from experts such as yourself, in a way that a blog post couldn’t. So I’m particularly grateful for your specific suggestions for changes.

> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf@coredump.cx]
> Sent: mardi 27 mai 2014 17:53
> To: GALINDO Virginie
> Cc: public-web-security@w3.org; Appelquist Daniel (UK)
> Subject: Re: [W3C Web Security IG] capability URLs
>  
> Hey,
>  
> I'm not 100% sure what are the goals of this spec. I think it glances over many important  
> use cases and provides rules that aren't universally applicable; while its potentially  
> most useful part - the explanation of how to safely construct the URLs - is just a single  
> sentence without the discussion of the appropriate sources of randomness, amount of  
> entropy, signing / expiration algorithms, etc.

I’d be really grateful for more specific use cases if you can suggest them. I’d also appreciate some pointers to specific advice about the safe construction of URLs that I could integrate, if you’re able to provide them. I’ve added a placeholder Issue for that; it might be that Alex or other members of the TAG can help.

> I don't want to be very negative, but it feels more suited for a blog post than a standard...  
> Nevertheless, if it's really getting written, I'd just add that capability-bearing  
> URLs are often present in conjunction with authentication, or for purposes that are  
> orthogonal to it. For example, a URL that contains a session-bound XSRF protection token  
> falls into this category (and disclosing it would be a problem). Another probably worthwhile  
> use case is for providing access to documents that are inherently unsafe to host in authenticated  
> / sensitive origins within an otherwise authenticated
> session:
>  
> http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html  

I’ve added wording to the effect that authentication and capability URLs can be used in combination. I’ve also referenced out to the use case you reference above, but I’m afraid that the blog post glosses over some details that are probably glaringly obvious to a security expert but less so to normal web developers such as myself and the target audience of the document. I’ve added an Issue here:

  http://w3ctag.github.io/capability-urls/#managing-access-on-sandboxed-domains

and I hope that you might be able to provide more details to help me expand this section. A concrete use case like the others listed in Section 2 would also help I think.

> Several other nits:
>  
> "If a link to another site is followed on a page accessed through a capability URL, that  
> site may be notified of the capability URL through the Referer HTTP header." - third-party  
> subresources (e.g., images or ads embedded on the page) are an even more insidious risk  
> that clicking on links.

Yes, I was using the term ‘links’ in its generic sense rather than in the sense of clickable links. I’ve added wording to clarify.

> "Third party scripts within a page accessed through a capability URL can access that  
> URL and potentially record it elsewhere." - having malicious third-party scripts on  
> your pages is a fundamental security issue that isn't made much worse by capability-bearing  
> URLs.

That’s true, but I think it’s worth pointing out specifically that it is a vector for the sharing of capability URLs, in this context.

> "It can be hard to detect when a capability URL has been compromised, because there is  
> nothing to distinguish legitimate access from illegitimate access." - is this different  
> for compromised HTTP cookies or passwords?

Fair point, I’ve removed the section.

> "For example, an HTTP GET on a capability URL should not result in side effects such as  
> the deletion of a resource." and "Pages that inform users of capability URLs should be  
> encrypted, by being served through HTTPS." - many (if not most) capability-bearing  
> URLs are delivered over e-mail and used for single-click confirmations of actions such  
> as subscribing to a mailing list. Without providing alternatives or carve-outs for  
> such use cases, the advice is probably not ideal.

Sure. The use of “should” in this section is deliberate. But I’ve also added a Note to explicitly say that when the URL is shared by email you have to employ those techniques that you can employ rather than those that you can’t.

> "When capability URLs expire, servers should respond to the URL with either a 410 Gone  
> or a 404 Not Found response." - why, for URLs intended for human use? The underlying resource  
> is found, the server just doesn't like the access token anymore.

What do you think the response code should be? A 403 Forbidden? If that is the only response that will be given from the URL isn’t it more accurate to say that it’s 410 Gone (or 404 Not Found which everyone uses to mean the page isn’t there any more)?

> "To prevent the capability URL from being visible in the location bar, you can use the  
> replaceState() method to replace the displayed URL with the canonical URL." / "[...]  
> obscuring the location bar [...]" - what does this accomplish, if in most circumstances,  
> the URL is still visible before it is followed?

It’s a slight risk reduction in over-the-shoulder attacks. The URL appears in the location bar for a lot longer (and with a clear association with interesting content) than it appears in the status bar when hovering over a link prior to clicking it. That’s assuming the status bar is what you’re referring to wrt the URL being visible before being followed?

Thanks again for your comments,

Jeni
--  
Jeni Tennison
http://www.jenitennison.com/

Received on Tuesday, 3 June 2014 14:09:41 UTC