Re: ACTION-278 Hiding metadata for security reasons

Tyler Close writes:

> Good Practice: URI assignment authorities SHOULD NOT put confidential
> metadata in a URI whose protocol does not support confidentiality.

Tyler, thank you for the toughtful comments.  I think what surprises me 
about the above is the presumption that the URIs themselves are in common 
cases restricted to use with particular protocols.  Perhaps I'm 
misunderstanding,  but do you refer to protocols like HTTPS used with URI 
schemes such as https?  My concern is that, even when such URIs and 
protocols are used, the URIs themselves may be available in the clear, 
e.g. in the client, or in pages linking the resource, or perhaps even in 
certain intermediaries or logs.  The advice not to put confidential 
information in URIs at all was motivated in part, I think, by such 
concerns.  I feel like I'm probably missing something about your proposal, 
as I'm sure you've thought of such things.  Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Tyler Close <tyler.close@gmail.com>
Sent by: www-tag-request@w3.org
12/27/2009 02:20 PM
 
        To:     Jonathan Rees <jar@creativecommons.org>
        cc:     www-tag@w3.org, "Mark S. Miller" <erights@google.com>, 
(bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: ACTION-278 Hiding metadata for security 
reasons


There's an interesting contradiction in the original text that I think
indicates how the section should be rewritten. The original text is:

"""
A bank establishes a URI assignment policy in which account numbers
are encoded directly in the URI. For example, the URI
http://example.org/customeraccounts/456123 accesses information for
account number 456123. A malicious worker at an Internet Service
Provider notices these URIs in his traffic logs, and determines the
bank account numbers for his Internet customers. Furthermore, if
access controls are not properly in place, he might be able to guess
the URIs for other accounts, and to attempt to access them.

Good Practice: URI assignment authorities SHOULD NOT put into URIs
metadata that is to be kept confidential.
"""

The last sentence of the body text correctly points out that the
ability to guess the URI for a confidential resource is dangerous.
Discovering the URI of a confidential resource is crucial to mounting
a CSRF or clickjacking attack, as well as other related Confused
Deputy attacks. Therefore, an obvious deduction from the body text is
that the URI for a confidential resource should not be guessable, and
should be kept confidential. The "Good Practice" conclusion of the
section then flatly contradicts the body text of the section.
Essentially, a URI for a confidential resource is itself metadata that
is to be kept confidential.

I think the current section 2.7 should be split into two new sections
that correctly address the concerns raised in the current body text.
The first would motivate:

Good Practice: URI assignment authorities SHOULD NOT put confidential
metadata in a URI whose protocol does not support confidentiality.

The second section would motivate:

Good Practice: URI assignment authorities SHOULD identify a
confidential resource using a URI whose protocol provides
confidentiality.

Good Practice: URI assignment authorities SHOULD identify a
confidential resource using an unguessable URI.

I am happy to provide body text for these two new sections.

I don't like Jonathan's proposed replacement text, since my impression
is that it only begrudgingly condones the use of unguessable URIs;
whereas I think the TAG should be enthusiastic supporters of them. As
I've argued in my web-key paper <http://waterken.sf.net/web-key>,
unguessable URIs provide a way to implement access-control that
leverages the principles documented in webarch; whereas password based
techniques are in direct conflict with webarch.

The metadata in URIs finding should clearly explain the virtues of
unguessable URIs and express the TAG's support for use of them.

--Tyler

On Sun, Dec 27, 2009 at 8:46 AM, Jonathan Rees <jar@creativecommons.org> 
wrote:
> Regarding ACTION-278, here is preliminary draft text to add to the end
> of section
> 2.7 "Hiding metadata for security reasons" of TAG finding "The use of
> Metadata in URIs" [2]
>
> Criticism welcome; I'm expecting I'll have to substantially revise in
> the face of
> the wisdom to be precipitated.
>
> <snip>
>
> In special circumstances where URIs are adequately protected for the
> application in question, it may be safe to create URIs that carry
> sensitive metadata.  Most risks associated with metadata payloads are
> avoided when the following rules are respected:
> 1. the URI conveys only specific, limited knowledge or authority
> 2. the URI protects the information it carries by a level of
>   obfuscation such as encryption and/or indirection via a random key
> 3. the URI is confined to secure data paths
> 4. the URI is restricted to a single use and/or is valid only during a 
limited
>   lifetime
>
> For example, a calendar system may provide an option to share a
> calendar with another user.  The access right may be designated by a
> unguessable URI that can be sent to the other user, who on applying it
> obtains read access in a coordinating mail application to the first
> user's mailbox.
>
> Adequacy of data path security is difficult to assess and great care
> should be exercised in using this pattern.  The calendar case works
> because the URI in question has special use contexts (it is not likely
> that is will be used for general browsing or bookmarking), it conveys
> limited authority (read access to one calendar, not login access to an
> email account), email and HTTP connections are assumed to be
> sufficiently private, and the providing and consuming applications
> both take steps to minimize disclosure risks.
>
> </snip>
>
> Best
> Jonathan
>
> [1] http://www.w3.org/2001/tag/group/track/actions/278
> [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31#hideforsecurity
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Sunday, 27 December 2009 20:00:46 UTC