Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

On 12/02/2009, at 5:26 AM, Adam Barth wrote:

> On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w3c@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/

Received on Thursday, 12 February 2009 11:23:24 UTC