Re: ACTION-278 Hiding metadata for security reasons

On Mon, 2010-02-08 at 17:44 -0800, Tyler Close wrote:
> 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:

I read this when you 1st sent it, and I didn't see anything
I felt strongly about... but I realize that unless I reply,
nobody knows whether I even read it...

The prose mostly works for me; I'm still mulling over some
of the choice of terms.

The 2nd good practice note surprised me a little; it made
me want to back up and see if the text before it actually
justified it. I'm still mulling it over.

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


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 9 February 2010 19:42:43 UTC