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 Tuesday, 9 February 2010 01:44:49 UTC