On Sat, May 7, 2011 at 11:54 AM, Kyle Simpson <[email protected]> wrote:
> The malicious script could schedule patching newly loaded code >> directly without even overwriting Object.prototype (eg. to reuse your >> example, it could replace document.location.href occurences with a >> string constant in the 'trustworthy' function source directly). >> > > Not if the code in question is inside a self-executing function closure, > which is a pretty common pattern. In that case, the only "vulnerability" to > trusting what you see from `Object.prototype.toString` (or > `location.href.toString`) is if it's possible that someone paved over them > earlier, either intentionally or accidentally. > > > > This means forbidding overwriting properties of Object.prototype would >> be 'security by obscurity' at best imho. >> > > I already acknowledged that it's only one tiny piece of the overall "code > security" discussion... but it would certainly help a few of those use-cases > to be more secure. > > Maybe the more appropriate term instead of "secure" is "reliable". For > example, the case of testing for the validity of `window.opera`... that > special object could be more trusted/reliable (not faked or accidentally > collided with) if it was impossible to fake the output of > `Object.prototype.toString.call(window.opera)`. > > > > On 1:44 PM, Douglas Crockford wrote: >> I agree that the primordials should have been frozen, but as Brendan >> says, that ship has sunk. But a smart library can now do that job, so a >> page can elect to have the benefit of frozen primordials if it wishes. >> > > 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. I've been at this for a while, as has Crock. I doubt there's any realistic scenario where code loaded later into an already corrupted frame can usefully defend its integrity. If you know of a way to defend against this rewriting attack, please explain it. Thanks. > > And "ships being sunk" not withstanding, I think it's a valid question if > something like this could be a future candidate for a more "strict" (opt-in) > JavaScript, like Harmony/Harmony.Next or "strict mode" itself. > We are currently prototyping such a SES (Secure EcmaScript) proposal, for now as a smart library written in ES5. See < http://codereview.appspot.com/4249052/> for its current in-review state. (Although it already got one LGTM from mzero, I'm waiting on another review before committing.) The security of this library absolutely depends on being run before anything potentially malicious is run in the same frame. > > > --Kyle > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
