- From: <sird@rckc.at>
- Date: Sun, 30 Jan 2011 21:48:09 -0600
- 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>
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:49:02 UTC