Re: ACTION-278 Hiding metadata for security reasons

On Tue, Feb 16, 2010 at 4:29 PM,  <noah_mendelsohn@us.ibm.com> wrote:
> 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.

In that case, we have no problem. In the quoted text, I am only
talking about point #1. The "it" you're confused about refers to the
metadata, so the current sentence:

"Including confidential, but guessable, metadata in a URI can make it
vulnerable to a guessing attack."

could be rewritten as:

"Including confidential, but guessable, metadata in a URI can make
that metadata vulnerable to a guessing attack."

The text in the current finding does a poor job of explaining why it's
dangerous to put metadata like a bank account number in a URL. An ISP
employee is a much more powerful attacker that is required to make the
point. Some developers may feel defending against such a powerful
attacker is outside their threat model. Still others may reason they
can make this practice safe by using HTTPS, since it encrypts the
requests and so prevents the ISP employee from directly reading the
URL. In contrast, the text from my proposal makes it clear that any
ordinary user is a sufficiently powerful attacker to make the practice
unsafe and that using HTTPS does not help.

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

My proposed text doesn't make any such demands of general software. It
only puts into writing part of the security model currently
implemented by user-agents. Do you object to anything in the proposed
text? Can you provide any specific examples of deployed user-agent
behavior that is non-compliant with the proposed text?

> Thus, it's generally appropriate to
> use some sort of out-of-band access control mechanism to achieve reliable
> access control.

Out-of-band access control doesn't actually work, let alone provide
"reliable" access control. My proposed text explains three distinct
categories of attack against such attempts at access control: CSRF,
clickjacking and timing attacks. Do you dispute any of the arguments
made in my proposed text?

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

I've been making the case that guessable URLs for private resources
are not safe and that what you call "explicit security mechanisms" are
neither explicit nor secure, rather they are ambient and subject to a
variety of attacks. Cookies, HTTP auth and such are not "explicit"
since they are always *implicitly* added to requests, rather than
being explicitly provided by the requesting content. In contrast, an
unguessable URL is explicit, since it must be explicitly provided by
the requesting content.

In addition to these logical problems, the text in that email seems
designed to denigrate web-keys. I'm not sure why you think that text
represents a possible point of agreement.

In contrast, the text I've proposed side-steps the controversy over
whether or not a web-key should be sufficient to grant access to a
resource. Instead, the text focuses on the dangers of guessable URLs.
I think the case I've laid out against guessable URLs is very strong
and presents a practical point of agreement on this issue. I look
forward to reading your comments on the rest of this proposed text.

--Tyler

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



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

Received on Wednesday, 17 February 2010 07:14:54 UTC