[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
mjs at apple.com
Mon Sep 29 21:22:33 PDT 2008
On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote:
> Michal Zalewski wrote:
>> I kinda assumed this suggestion was tongue-in-cheek, but if not -
>> banning cross-domain IFRAMEs to fix one flaw, without providing
>> viable methods for sandboxing untrusted same-origin content, would
>> leave web developers with no tools to deal with quite a few classes
>> of major security issues.
> It's tongue-in-cheek that I don't expect it to be adopted or
> seriously considered (this year). It's not tongue-in-cheek in that I
> very much wish it were adopted. That is, I think it's in the realm
> of the desirable, not the possible.
> I am curious what issues you see with same origin content. They
> certainly exist, but I tend to feel those are orthogonal to the
> issues at hand, and subject for a separate discussion.
> I do think we have an existence proof that security in this realm is
> possible. That's Java. Modulo some outright bugs in VMs (since
> repaired) the default Java applet security model has worked and
> worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict
> enough.) I have seen no security design flaws exposed in Java
> applets in over ten years. That's why I suspect duplicating Java's
> security policy in HTML is a safe way forward. I'm skeptical that
> anything less will suffice.
Java's security policy is also looser in some ways. For example, it
allows the applet to connect to any port on the origin server. This
has at times caused Java applets to be subject to vulnerabilities that
did not affect plain HTML+JS+CSS (more recently than in the past 10
years). The general Web same-origin policy considers the port as well
as the host to be part of the origin.
More generally, I am on Apple's internal incoming security bug list,
and I see Java applet security bugs all the time, so I think whatever
the strength of the model may be, it does not lead to Java applets
being secure in practice.
And finally, the key question for whether strict same-origin can work
it not one of security but of functionality and usability. The trend
in recent years has been for browsers to punch more controlled holes
in the same-origin policy to fulfill the frequent desire of Web
application developers to communicate with other servers from the
client side. This is desirable so that "AJAX" apps (where most of the
logic and functionality is client-side) can make use of third-party
Web services APIs, in the same way that native apps can, without
having to round-trip through their own server. I do not see this trend
reversing any time soon.
In conclusion I think limiting the Web to 100% strict same-origin
would not be desirable even in an ideal world where compatibility
issues are not a concern.
> I don't expect this to happen, however, because many large players
> are exploiting existing security design flaws in the web to do
> things they shouldn't be allowed to do in the first place,
> especially tracking users. Any scheme that limits the ability of
> advertisers and others to track users will be strenuously resisted.
For the record, neither Apple nor the WebKit project have any strong
commercial interest in the ability of advertisers or others to track
More information about the whatwg