Mark S. Miller
erights at google.com
Sat May 7 16:40:44 PDT 2011
On Sat, May 7, 2011 at 1:17 PM, Kyle Simpson <getify at gmail.com> wrote:
> Again, a "smart library" can only do that if it's guaranteed to be the
>>> first code to run on the page. If not (which is usually the case), then all
>>> bets are off, unless the language offers some protections.
>> All bets are probably still off. The malicious code that's first can load
>> the latter virtuous code as data using cross-origin XHR, or, if the script
>> isn't served with an "Access-Control-Allow-Origin: *", via server-side
>> proxying. Then the malicious code can rewrite the virtuous code as it wishes
>> before evaling it.
> My first reaction to this assertion is to say: "so?" It's a rather moot
> argument to suggest that code which can be altered before it's run isn't
> trustable... of course it isn't. [...] because any malicious script (if it's
> first on the page) can completely hijack another part of the page? Yup, I
That was my point. Since you agree, I don't understand your point:
Again, a "smart library" can only do that if it's guaranteed to be the first
> code to run on the page. If not (which is usually the case), then all bets
> are off, unless the language offers some protections.
What protections do you have in mind? And how, were your protections to be
adopted, would all bets no longer be off when loading a virtuous library
into a frame in which malicious code had already run first?
[...] If CORS basically completely eliminates any of the protections that
SOP gave us, then CORS is a failed system.
CORS is not the issue here. In the absence of any
Access-Control-Allow-Origin headers, or if we hypothetically remove CORS
from the picture, then the unsolvability remains because of server side
> All this is a moot discussion though, because malicious take-over's of a
> page are nothing but an exotic edge case, and only enabled if people "do it
> wrong". The original request stemmed NOT from the malicious hacker scenario,
> nor from a page "doing it wrong" (per se), but from the "oops, some other
> piece of dumb code earlier on the page accidentally screwed up and collided
> with something I need to be inviolate."
Some people's edge cases are other people's central focus. Your message was
a response to Crock's claim, which clearly regards issues of malice, not
merely accident, as central.
As for accident, it depends how dumb that earlier piece of code was. If it
modifies primordial methods so that they no longer satisfy their contracts
in way that later code is ignorant of and unprepared for, then again, it's
hard to do any practical and correct JS coding under platform assumptions
this weak. See the thread starting at <
OTOH, if these earlier dumb scripts are not that dumb, then the later smart
library should still be able to succeed. As a concrete test case, we should
ask what kind of primordial-contract-preserving damage an initial
dumb-but-not-malicious early script might do that would invalidate the
protections the SES library provides. I think this should be an interesting
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss