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

Re: CSP XML Data with tokens

From: <sird@rckc.at>
Date: Sun, 30 Jan 2011 21:48:09 -0600
Message-ID: <AANLkTinRZuZDrybMJ6_fk_sSG04s1uA1fNbkZabPoC7v@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
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>

Isn't that over simplified?

Eg. you won't do:

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

You do:

$untrusted = "untrusted nonce='".getrandomoutoftheair()."'";
 Hi, <$untrusted>$first_name $last_name</$untrusted>, your e-mail is

Since I assume the use of "$" makes reference to PHP, so one would
have to open a handle to /dev/random, and seed mt_rand safely first.

How would you do that in AppEngine for example? Or in a server with
open base dir that disallows you to read anything on root (like /dev).

I know there are answers to those questions but makes everything harder.

Said that, there's still the problem of old UAs.. that we sadly have
to live with =(

If this solution includes htmlentifying the content, then that would
be safe, and backwards compatible.. But in that case, why not use the
aforementioned iframe.

-- Eduardo

On Sun, Jan 30, 2011 at 9:10 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
> 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:49:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC