RE: [W3C Web Security IG] capability URLs

Michal,
I don’t want to talk instead of the editor, Jeni Tennison, but it is clearly stated that this document in not intended to be a recommendation - I guess a note would be an appropriate format. I am adding the TAG mailing list to allow them to follow up on your comments.
Regards,
Virginie



-----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 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


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.

"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.

"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?

"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.

"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.

"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?

On Tue, May 27, 2014 at 8:08 AM, GALINDO Virginie <Virginie.GALINDO@gemalto.com> wrote:
> Hi all,
>
>
>
> W3C TAG is currently working on a new specification named Capability
> URL, and they are expecting feedbacks.
>
> Here is why and what
> http://www.w3.org/blog/TAG/2014/05/22/capability-urls-feedback/

>
> And the spec expecting your comments is here
> http://www.w3.org/TR/capability-urls/

>
>
>
> Regards,
>
> Virginie
>
> Gemalto
>
> Co-chair of Web Security IG
>
>
>
>
>
> Note : Extract Capability URL Section 1 Introduction
>
> […]
>
> There are two broad methods of controlling access to information that
> is published on the web:
>
> the server can have access control measures that require people
> accessing the content to provide the correct token(s) (such as a
> password) before the content is accessible the information can be
> published at an obscure or unguessable URL, and links to it only
> provided to people who have permission to access it
>
> The URLs used in the second method are known as "capability URLs": an
> agent who possesses the URL is given the capability to access the information.
>
> This document describes:
>
> cases where capability URLs are used on the web today advantages and
> disadvantages of using capability URLs to control access to content
> design considerations when creating websites that use capability URLs
> areas of technical development to support the use of capability URLs
>
> […]
>
>
>
>
> ________________________________
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus
________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Monday, 2 June 2014 14:23:05 UTC