W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: CSP XML Data with tokens

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 29 Jan 2011 22:21:58 -0800
Message-ID: <AANLkTi=65insi__ftkoBYUnO9QkjEaG_YWboxb=CRX3F@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 January 2011 06:23:20 GMT