On Sat, May 7, 2011 at 1:17 PM, Kyle Simpson <[email protected]> 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 > agree. 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 proxying. ------------ > 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 < https://mail.mozilla.org/pipermail/es-discuss/2011-April/013654.html>. 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 question. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
