W3C home > Mailing lists > Public > public-web-security@w3.org > May 2014

Re: [W3C Web Security IG] capability URLs

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Tue, 27 May 2014 08:52:58 -0700
Message-ID: <CALx_OUDCYH7k78CV1cS28jCzBdMicar9gP7LFVrTHpcR4b1VOA@mail.gmail.com>
To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>, "Appelquist Daniel (UK)" <Daniel.Appelquist@telefonica.com>
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
Received on Tuesday, 27 May 2014 15:53:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:21 UTC