[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

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  
users.

Regards,
Maciej

Received on Monday, 29 September 2008 21:22:33 UTC