Re: WGLC #348: Realms and scope

On 7/06/2012 4:21 p.m., Manger, James H wrote:
> David,
>
> A user browsers to
> (1) https://example.com/good/
> Gets as 401 response with realm="GoodStuff"; is prompted for credentials; the request is retried successfully with the credentials in the Authorization header.
> Now the user browsers to
> (2) https://example.com/good/sub/ and
> (3) https://example.com/bad/.
>
> The issue isn't whether a browser will automatically send the credentials in request 2, but not in 3.
>
> The issue is whether a browser will automatically send the credentials if request 3 responds with a 401 with realm="GoodStuff". Browsers should do this, and they do (at least Chrome on Windows in a very quick test).
>
> A /bad/ resource can get the /good/ credentials by pretending to be in the same realm.

So, we have a server which is authoritatively hosting 2+ parties using 
the same scheme+FQDN+port+realm. Thats a four-factor scoping key; with 
two factors locked to the reading protocol [scheme+port], one factor 
locked to particular ownership/authority [FQDN] and some very weak 
salting [realm text]. The "insecurity" is only created by someone 
administratively undermining two of the four reliability factors 
(FQDN+port) which leaves an attacker with only the weakest factor 
(realm) to undermine for credentials to leak.

The key point [pun intended] being that for any of this to matter in the 
slightest there *first* has to be an administrator willingly removing 
uniqueness from the most critical parts of the algorithm key. So long as 
that continues there is no fixing it *for them*.

IMHO the text says there is a crossover issue and part of how to fix, 
but does not clearly state the problem is not with realm directly but 
from the sharing of authority-URI

> This is the limitation of realms that the proposed Security Considerations text addresses [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/348].
>
>    Authentication schemes that use the "realm" mechanism for establishing a
>    protection space will expose credentials to all resources on a server.

NP: personally I'm not sure we can say it that generically. Some may use 
realm, but also use a target space internally to restrict the scope 
where that realm is relevant/valid.

Perhapse s/use/rely solely on/. Which implies the current Basic and 
Digest without limiting it by naming them.

>   Clients
>    that have successfully made authenticated requests with a resource can
>    use the same authentication credentials for other resources on the same
>    server. This makes it possible for a different resource to harvest
>    authentication credentials for other resources.
>
>    This is of particular concern when a server hosts resources for multiple
>    parties.

IMHO, this needs to be clearer than "server" since that implies all 
types of virtual hosting as well which are actually not guilty of this 
brokenness.
Perhapse more words at the end of that sentence to the effect of "under 
the same hostname." or similar.

>   Possible mitigation strategies include restricting direct access
>    to authentication credentials (i.e., not making the content of the
>    Authorization request header field available), and separating protection
>    spaces by using a different host name for each party.
>
>
> A server that enforces different realms values for different parties might theoretically mitigate the risk, without the more destructive blocking of direct access to the Authorization header. However, I wouldn't be surprised if, say, javascript returned from /bad/ could somehow get the credentials the browser is caching for /good/.


AYJ

Received on Thursday, 7 June 2012 09:18:13 UTC