On Fri, Nov 4, 2011 at 11:46 AM, David Herman <dher...@mozilla.com> wrote:
> This is the only one I've seen that seems like it should work, but it > depends on whether SES/Caja/etc have some sort of way of neutering > __proto__. Just from hacking around, I don't see much way of censoring it > in SpiderMonkey. > > MarkM, do you have any tricks for censoring __proto__? > Not censoring, no. However, for code that follows the following best practices, uncensored __proto__ should be harmless. 1) Avoid objects as maps -- use Maps as maps. 2) Always use array[+i] for numeric indexing. Note that this can still access properties named 'NaN', 'Infinity', and '-Infinity'. 3) Always freeze, or at least seal, objects potentially exposed directly to untrusted clients. #3 is crucial, and works because ES5.1 section 8.6.2 says: "if [[Extensible]] is false the value of the [[Class]] and [[Prototype]] internal properties of the object may not be modified. Once the value of an [[Extensible]] internal property has been set to false it may not be subsequently changed to true." This is tested by test262 at < http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch08/8.6/8.6.2/S8.6.2_A8.js >. The visible development tip of all major browsers except Opera 12 alpha build 1116 already implement this restriction. initSES.js considers that Opera unsafe for this reason. Nevertheless, if I could cheaply censor __proto__ I would. Since I'm not, I am *very* curious is this leaves open other attacks against code obeying the above best practices. If any of you see some other avenue of attack, *please* let me know. Thanks. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
