On Wed, Feb 11, 2009 at 2:01 PM, Adam Barth <w...@adambarth.com> wrote:
> On Wed, Feb 11, 2009 at 1:46 PM, Breno de Medeiros <br...@google.com> > wrote: > > The current proposal for host-meta addresses some use cases that today > > simply _cannot_ be addressed without it. > > I'm not familiar our process for adopting new use cases, but let's > think more carefully about one of the listed use cases: > > On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros <br...@google.com> > wrote: > > 1. Security critical ones, but for server-to-server discovery uses (not > > browser mediated) > > To serve this use case, we should require that the host-meta file be > served with a specific, novel content type. Without this requirement, > servers that try to use the host-meta file for security-critical > server-to-server discovery will be tricked by attackers who upload > fake host-meta files to unknowing servers. > > > Your proposal restricts the > > discovery process in ways that may have unintended consequences in terms > of > > prohibiting future uses. > > How does requiring a specific Content-Type prohibit future uses? > > > This is so that browsers can avoid implementing > > same-domain policy checks at the application layer? > > No, this is to protect servers that let attackers upload previously > benign content to now-magical paths. 1. The mechanism is not sufficient strong to prevent against defacing attacks. An attacker that can upload a file and choose how to set the content-type would be able to implement the attack. If servers are willing to let users upload files willy-nilly, and do not worry about magical paths, will they worry about magical content types? 2. This technique may prevent legitimate uses of the spec by developers who do not have the ability to set the appropriate header. Is this more likely to prevent legitimate developers from getting things done than to prevent attacks from spoofing said magical paths? I would say yes. Defacing attacks are a threat to applications relying on this spec, and they should be explicitly aware of it rather than have a false sense of security based on ad-hoc mitigation techniques. For instance, for XRD discovery there is work on a trust profile using signatures that operates on the basic principle that 'the way to get the resource is fundamentally untrustworthy, let the resources be self-validating.' > > > Adam > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
