- From: Breno de Medeiros <breno@google.com>
- Date: Mon, 23 Feb 2009 11:47:51 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Ben Laurie <benl@google.com>, Mark Nottingham <mnot@mnot.net>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
- Message-ID: <29fb00360902231147m1f6d1724r8232cd4f76c6fb81@mail.gmail.com>
On Mon, Feb 23, 2009 at 11:34 AM, Adam Barth <w3c@adambarth.com> wrote: > On Mon, Feb 23, 2009 at 10:13 AM, Breno de Medeiros <breno@google.com> > wrote: > > Every application _will_ need to use different processing rules, because, > > well, they are interested in different things. > > Applications will be interested in different facts in the host-meta > store, but why should they use different procedures for obtaining the > host-meta store? They might as well use different stores entirely. Or they may have to do it because host-meta does not allow redirects and they need it. I wonder what is more likely. > > > > What is the attack model here? I assume is the following: The attacker > > compromises the server to serve a re-direct when there should be a file > > served (or a 404). Well, the attacker can't upload a host-meta with what > it > > wants in it? Why? > > Often users can add redirects to a server without the ability to > upload content to that serve. For example, tinyurl.com/host-meta now > redirects to a URL I control even though I have no ability to upload > content to tinyurl.com. Why should I be able to set host-meta > properties for tinyurl.com? Because tinyurl.com allows you to do this. > > > > Perhaps that argument would be more convincing when you provide an > example > > of an attack made possibly by introduction of a redirect that would not > be > > possible by, say, adding a line to the host-meta file. > > Ok. I own tinyurl.com's host-meta store because of redirects. > Without redirects, I don't know how to own their host-meta store. I am more imaginative: I could do DNS spoofing, or I could choose another site to hack that is actually more interesting that tinyurl. After all, tinyurl is just a gigantic open redirector so it is already an enormous security nightmare for many reasons like phishing attacks and malware distribution. But maybe then I would have to come up with a less contrived example. > > > Adam > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
Received on Monday, 23 February 2009 19:48:30 UTC