<div dir="ltr">On Sun, Sep 28, 2008 at 12:41 AM, Michal Zalewski <span dir="ltr"><lcamtuf@dione.cc></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sat, 27 Sep 2008, Robert O'Callahan wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Default permission of cross-domain loads is responsible for *a lot* of problems. Allowing sites to escape that would address a lot of problems, even if it is opt-in. Eventually we could hope to reach a state where all browsers support it, and most sites request it --- a much saner Web IMHO.<br>

</blockquote>
<br></div>
Yup, by all means, it solves a lot of other problems - and devising a *comprehensive* solution (not a new specialty HTTP header to deal with IFRAMEs and OBJECT/EMBED/APPLETs specifically), even if opt-in, has the benefit of actually reducing complexity for web app developers (in terms of custom XSRF / script inclusion checks, etc, that they could ditch).</blockquote>
<div><br>Glad you think so.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The issue is, a considerable implementation effort is involved in most of these comprehensive designs (given how current same-origin checks, and code taking cross-domain actions with no same-origin checks, is typically scattered), lots of open questions (e.g., there are some important performance trade-offs depending on the granularity of resources, the types of requests we want to run checks on; site-wide policies and per-URL policies; etc).<br>

<br>
On top of that, there seem to be several incompatible proposals from various groups, with vendors seemingly not willing to back off. Microsoft is pursuing their proposal for cross-domain policies in MSIE8, Mozilla devs had another (and every other security researcher has probably their "own and better" design in the drawer, about to bring it out the moment they are asked for advice).</blockquote>
<div><br>I'm not sure what you're talking about here. I'm specifically NOT talking about Content-Restrictions or Site-Security-Policies or any other policies for controlling what a page may do once it has loaded.<br>
<br>I'm expressing approval for your option 1, "X-I-Do-Not-Want-To-Be-Framed-<div id=":1f5" class="ArwC7c ckChnd">Across-Domains: yes", preferably generalized to "X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes" so that it can be used for scripts and images too. On top of that, I'd add the W3C Access Controls spec for finer-grained control --- a spec that all the major vendors have signed on to. (So I'm really suggesting "X-Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes".)<br>
</div><br>I think this would be much easier to implement than your option 3. Option 3 requires hooking into layout, rendering, and event handling, and doing constant ongoing checks and state changes where we currently don't have any security checks. Furthermore there's an ongoing maintenance burden as every new layout and rendering feature has to be security-analyzed to see if it need to participate in the option 3 algorithm, and hooked up if so. OTOH option 1 requires only checks at load time, where we're already doing a lot of checks.<br>
<br>But feel free to ask other implementors what they think.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bottom line is, I would be very surprised if such a functionality would be in a state that can be relied upon by web applications in the next 5-8 years (more if the abysmally slow MSIE6 -> MSIE7 migration is bound to repeat with next major versions)... and I am not entirely comfortable with UI redress attacks being around for so long; I suppose most browser vendors are not happy too, given the recent / likely upcoming press attention.<br>

</blockquote><div> <br>So what? The same goes for all your options --- slow browser migration delays the uptake of any client-side solution. In fact, a solution that servers opt in to is likely to see *faster* client uptake because vendors and users will see a lower risk of Web applications breaking.<br>
<br>The real concern about an opt-in solution is Web apps taking a long time to use it. But it seems to me that most sites could just add the option 1 header for all pages on the site and the site would Just Work.<br></div>
</div><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>

</div>