Re: CSP XML Data with tokens

Oh I just noticed that on AppEngine you get a secure rng by default.

Well, disregard that then :)
-- Eduardo




On Sun, Jan 30, 2011 at 9:48 PM, sird@rckc.at <sird@rckc.at> wrote:
> Hi!
>
> 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.
>
> Greetings!!
> -- 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:53:19 UTC