- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 23 Jun 2008 23:17:20 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5776
Adam Barth <w3c@adambarth.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |w3c@adambarth.com
--- Comment #7 from Adam Barth <w3c@adambarth.com> 2008-06-23 23:17:19 ---
(In reply to comment #3)
> So this is a request for a way to override the type of a resource in an
> <iframe> from the HTML side?
If we do this, we should carefully consider the security implications of
overriding the server-provided Content-Type. For example, suppose a web site
lets users upload avatar images and serves the bytes of the uploaded images
with a Content-Type of image/gif. Now suppose the attacker uploads an HTML
document as his or her avatar. If the UA let's the attacker override the
server-provided Content-Type, the UA will execute the attacker's script in the
sites security context (i.e., the UA will have introduced an XSS vulnerability
into the site).
So some extent, sites already have to cope with browsers overriding the
server-provided Content-Type due to content sniffing. Many sites have spent
extensive effort reverse engineering UA content sniffing algorithms. For
example, Gmail pads text/plain attachments with 512 space characters to foil
IE's text/plain sniffer. Explicitly overriding the Content-Type, say to
text/html, would defeat this countermeasure and introduce an XSS vulnerability
into Gmail.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 23 June 2008 23:17:54 UTC