RE: WGLC #348: Realms and scope

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.

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

--
James Manger

> -----Original Message-----
> From: David Morris [mailto:dwm@xpasc.com]
> Sent: Thursday, 7 June 2012 3:38 AM
> To: HTTP Working Group
> Subject: Re: WGLC #348: Realms and scope
> 
> 
> 
> On Tue, 5 Jun 2012, Julian Reschke wrote:
> 
> > On 2012-06-05 02:16, David Morris wrote:
> > > ...
> > > This took a few days to set up a careful test case. I don't have
> the time
> > > or resources to test every client, so I can't refute the claim that
> some
> > > clients send the authorization header for a part of the hosts
> content
> > > which it doesn't apply to, but I've tested:
> >
> > What's the definition of "doesn't apply to"?
> 
> >From memory ... which has stuck with me because I wasn't real happy
> with the definition ...
> 
> Thinking of URLs as representing the hierarachical name space
> we commonly associate with a file system ...
> 
> Realm "RauthA" returned in a 401 response's www-authenticate header
> for a request for authab/a/ may be assumed to applu to directory
> authab/a/ and to all directories under authab/a/. So if the client
> has credentials for authab/a/ it may return those credentials
> in the Authorization header in a request for authab/a/aa/
> anticipating that the same credential would apply, but not for
> authab/ or any peer of authab/a/ such as authab/b/ in my test.
> 
> My current test setup doesn't support the subdirectory case, but
> I think I'll expand it when I get a chance.  I also need to go back
> and review the RFCs to validate my memory.
> 
> Dave Morris
> 
>

Received on Thursday, 7 June 2012 04:21:37 UTC