Re: ACTION-278 Hiding metadata for security reasons

Tyler Close wrote:

> Some kinds of identifiers are confidential, even though their value is
> guessable given a sufficient number of attempts. For example, a bank
> account number may be confidential even though a program could quickly
> enumerate all possible bank account numbers. Including confidential,
> but guessable, metadata in a URI can make it vulnerable to a guessing
> attack. 

I've responded to this before, but since the discussion seems to continue, 
I realize that among the things that bother me about the above is that it 
reads ambiguously, and I think the ambiguity is right at one of the points 
of disagreement between Tyler and me:

There are at least two sorts of security problems we might be talking 
about here:

I. Keeping the bank account number secret
II. Keeping those who aren't supposed to from reading of changing account 
information

The ambiguity I see is in the final sentence, where it speaks of making 
'it' vulnerable to a guessing attack.

I believe that the existing metdata in URI finding is, appropriately, 
dealing with potential vulnerability #1.  If you want bank account numbers 
to be secret, don't put them in clear text in URIs.

I believe that what Tyler intends to argue for is both #1 and #2, but 
especially #2.  That's what I have a problem with.  As I've said several 
times:  I believe that, in general, software that handles URIs should not 
in general be responsible for keeping those URIs secret.  (and as we've 
said several times, there is a wide range of such software...it's not just 
traditional "browser user agents"). Thus, it's generally appropriate to 
use some sort of out-of-band access control mechanism to achieve reliable 
access control.  As I've said several times:  I have no problem with 
implementations like Google Docs taking the risk of using URIs to encode 
access permissions, as long as the burden is on them to ensure that URIs 
are transmitted in a suitable secure way.

In an email about a week ago I proposed some text as a starting point for 
a revision to the metadata finding.  It's at the end of email [1].  I 
don't think I've seen any responses to it in email.  At the end of our 
telcon discussion last week [2] there was a bit of discussion of my 
proposal.  For me, a crucial difference when compared to Tyler's proposed 
text, is that I am avoiding any instruction as to what user agents SHOULD 
or MUST do.   Anyway, I would very much welcome comments on the proposal 
at the end of [1].

Noah

[1] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html
[2] http://www.w3.org/2001/tag/2010/02/11-minutes.html#item05



--------------------------------------
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
02/08/2010 08:44 PM
 
        To:     Dan Connolly <connolly@w3.org>
        cc:     Jonathan Rees <jar@creativecommons.org>, www-tag@w3.org, 
"Mark S. Miller" <erights@google.com>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: ACTION-278 Hiding metadata for security 
reasons


On Sat, Jan 23, 2010 at 1:12 PM, Dan Connolly <connolly@w3.org> wrote:
> On Sun, 2009-12-27 at 11:20 -0800, Tyler Close wrote:
>> I am happy to provide body text for these two new sections.
>
> I'd like to see that.

OK, here's a first draft of text for two new sections that motivate
two Good Practice statements:

"""
Guessable, confidential metadata

Some kinds of identifiers are confidential, even though their value is
guessable given a sufficient number of attempts. For example, a bank
account number may be confidential even though a program could quickly
enumerate all possible bank account numbers. Including confidential,
but guessable, metadata in a URI can make it vulnerable to a guessing
attack. By repeatedly attempting to dereference possible URIs and
monitoring the response, or even just the time taken to respond, an
attacker could guess confidential metadata and have the server confirm
its correctness.

Good Practice: A URI assignment authority SHOULD NOT put guessable,
confidential metadata in a URI.

Private resources

Some resources are private and so only intended for use by a single
user or group of users, instead of being publicly accessible to
everyone. Though someone outside this authorized group may not be able
to directly access the private resource, it may still be possible to
indirectly access the resource if it is identified by a guessable URI.
After luring an authorized user to an attack page, there may be
several avenues of indirect access. In a CSRF attack, the attacker's
page includes a HTML <form> tag whose action attribute contains the
guessable URI for the private resource. This <form> may be
automatically submitted using JavaScript, or the user may be induced
to click the submit button. In a clickjacking attack, the attacker's
page might include an iframe that references the guessable URI for the
private resource. By placing the private resource in an unexpected
context, the user may be induced to interact with it in an undesired
way. Though the Same Origin Policy may prevent the attack page from
directly reading responses returned from a private resource, the
attack page may still be able to time such responses and so detect the
state of the resource. For example, if the private resource is an
email archive, the attack page may be able to determine the frequency
of certain keywords by measuring the time taken for a search operation
to complete.

When a private resource is identified by a guessable URI an attacker
can navigate an authorized user to it under a pretense of the
attacker's choosing. In this unexpected context, the attacker can
cause the user to interact with the private resource in an undesired
way. By measuring response times, the attacker may also learn
significant confidential information about the private resource. Using
unguessable URIs, instead of guessable ones, prevents these attacks.

Good Practice: A URI assignment authority SHOULD only identify private
resources with unguessable URIs.

An unguessable URI only defends against these attacks if it is kept
confidential. A resource host SHOULD take precautions to ensure the
URI is only revealed to authorized users. To protect the URI from
network eavesdroppers, a protocol that supports confidentiality, such
as HTTPS, SHOULD be used. If the URL might appear in an HTTP Referer
header, the unguessable portion SHOULD be in the fragment component.
In all other cases, the unguessable portion SHOULD be in the query
component. Some software[1] for monitoring URI usage automatically
strips the query component from a URI before revealing it to a
third-party. Placing the unguessable portion of the URI in the query
component facilitates interaction with such software. A user-agent
MUST NOT disclose representations or URIs, unless either explicitly
instructed to do so by the user or as legitimately directed to by
presented content. Since the user may wish to keep this information
confidential, the user-agent must not assume it can be revealed to
third-parties.
"""

[1], such as IE, Alexa toolbar, Squid proxy, ...

--Tyler

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

Received on Wednesday, 17 February 2010 00:29:41 UTC