- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 29 Jan 2011 22:21:58 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: "sird@rckc.at" <sird@rckc.at>, Gareth Heyes <gazheyes@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Brandon Sterne <bsterne@mozilla.com>, "public-web-security@w3.org" <public-web-security@w3.org>
On Sat, Jan 29, 2011 at 9:43 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote: >> Anyways, I digress.. the conclusion, from my point of view is that we >> don't need XML data tokens if we have sandboxed iframes with srcdoc. > > I think there is a substantial advantage of being able to output small > chunks of untrusted data as-is - note that this is the problem this > sub-thread started with - and simply mark the relevant section of the > page as restricted in some way (no HTML parsing at all, no scripting, > no external subresources, etc). > > I sort of suspect that making this possible would be the single most > effective way to put a dent in XSS; certainly more convenient than any > restrictive, page-wide script policies. One way of doing that is using HTML entities. For example, you could use a base64 entity: &%SGkgTWljaGFsIFphbGV3c2tpCg==; That would expand to pure text without any fear of injection. Alternatively, you can imagine letting pages define their own HTML entities in some namespace: Hi &$username; where somewhere else we associate $username with "Michal Zalewski". Neither of those things requires any particular injustice to HTML syntax. Adam
Received on Sunday, 30 January 2011 06:23:16 UTC