On 12/02/2009, at 5:26 AM, Adam Barth wrote:
On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w...@adambarth.com>
wrote:
Adobe found the security case compelling enough to break backwards
compatibility in their crossdomain.xml policy file system to enforce
this requirement. Most serious Web sites opt-in to requiring an
explicit Content-Type.
By the way, here's the chart of the various security protections Adobe
added to crossdomain.xml and which version they first appeared in:
http://www.adobe.com/devnet/flashplayer/articles/fplayer9-10_security.html
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.
There is another one I forgot:
You need to restrict the scope of a host-meta file to a specific IP
address. For example, if suppose you retrieve
http://example.com/host-meta from 123.123.123.123. Now, you shouldn't
apply the information you get from that host-meta file to content
retrieved from 34.34.34.34. You need to fetch another host-meta file
from that IP address. If you don't do that, the host-meta file will
be vulnerable to DNS Rebinding. For an explanation of how this caused
problems for crossdomain.xml, see:
http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-
boneh.pdf
Sadly, this makes life much more complicated for implementers. (Maybe
now you begin to see why this draft scares me.)
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.
Cheers,
--
Mark Nottingham http://www.mnot.net/
