getify at gmail.com
Sat May 7 11:54:38 PDT 2011
> 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
> 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.
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)
More information about the es-discuss