- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 12 Feb 2009 10:10:29 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>, Breno de Medeiros <breno@google.com>
On Thu, Feb 12, 2009 at 3:13 AM, Mark Nottingham <mnot@mnot.net> wrote: > My inclination, then, would be to note DNS rebinding as a risk in Security > Considerations that prudent clients can protect themselves against, if > necessary. That sounds reasonable. On Thu, Feb 12, 2009 at 3:22 AM, Mark Nottingham <mnot@mnot.net> wrote: > From that document; >> >> Valid content-type values are: >> >> • text/* (any text type) >> • application/xml >> • application/xhtml+xml > > That's hardly "an explicit Content-Type"; it would be the default for a file > with that name on the majority of servers on the planet; the only thing it's > likely to affect is application/octet-stream, for those servers that don't > have a clue about what XML is. Interesting. I wonder how they came up with this list. The "text/*" value is particularly unsettling. /me should go hack them. By the way, Breno asked for examples of sites were users can control content at arbitrary paths. Two extremely popular ones are MySpace and Twitter. For example, I signed up for a MySpace account at http://www.myspace.com/hostmeta and I could do the same for Twitter. As it happens, these two services don't let you pick URLs with a "-" character in them, but I wouldn't hang my hat on that for security. > Adam, my experience with security work is that there always needs to be a > trade-off with usability (both implementer and end-user). While DNS > rebinding is a concerning attack for *some* use cases, it doesn't affect all > uses of this proposal; making such a requirement would needlessly burden > implementers (as you point out). It's a bad trade-off. I agree. Certainly not every use case will care about DNS Rebinding. Unfortunately, it will bite some application of host-meta at some point. Adam
Received on Thursday, 12 February 2009 18:11:04 UTC