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

Re: CSP XML Data with tokens

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Sun, 30 Jan 2011 19:10:16 -0800
Message-ID: <AANLkTi=1xOfEpB1UzGEPsB9zV2RVP=S9Bgrs+X7Bcp0g@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: Giorgio Maone <g.maone@informaction.com>, Adam Barth <w3c@adambarth.com>, 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>
To better explain my point, I can see people finding it more intuitive to do:

  Hi, <untrusted>$first_name $last_name</untrusted>, your e-mail is
<untrusted>$email</untrusted>.

(i.e., not having to worry what transformation to apply to the
offending content)... than they currently find it to do:

  Hi, $html_escape_variant3(first_name . " " . last_name), your e-mail
is $html_escape_variant3(email).

But I do not think it will be any simpler for them to do:

  Hi, $seamless_srcdoc_sandbox(first_name . " " . last_name), your
e-mail is $seamless_srcdoc_sandbox(email).

...and if they then see that the resulting document is littered with
incomprehensible base64 (and is necessarily slower to render), they
will probably develop a healthy aversion to this approach, too.

In fact, there are interesting semantic side benefits to the first
approach - think search engines and automated security testing, where
the ability to distinguish between owner-originating page content and
user-controlled parts would be extremely useful.

I might be wrong that the first approach is realistically any better
than the second; the difference is subtle. And in any case, we don't
know how to make it happen (DOM tree responses aside). But I'm really
puzzled as to why people think that the last approach is much more
likely to work than the second for that basic use case (it works OK
for a small subset of more complex ones).

/mz
Received on Monday, 31 January 2011 03:11:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 January 2011 03:11:10 GMT