- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 07 Jun 2012 12:17:12 +0200
- To: Amos Jeffries <squid3@treenet.co.nz>
- CC: ietf-http-wg@w3.org
On 2012-06-07 11:17, Amos Jeffries wrote: > ... >> 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. +1 > ... > 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. > ... We already have the term "canonical root URI" for that (but maybe we should think about a better term). Revised proposal: 6.2. Protection Spaces Authentication schemes that solely rely on 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 under the same canonical root URI (Section 6.2). 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. <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/348/348.diff> Best regards, Julian
Received on Thursday, 7 June 2012 10:17:46 UTC