[Webkit-unassigned] [Bug 151134] JS builtins should use secured functions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=151134

--- Comment #8 from youenn fablet <youennf at gmail.com> ---
Here are a bunch of additional thoughts.

In terms of coding style, it seems easier to secure JS built-ins when most of the code meat is implemented as internal functions and not as methods of the prototype or constructor. Whenever there is a need to access to a particular functionality, the internal function may be called in lieu of the object method.

For objects that are never exposed to user scripts, private methods of their prototypes are safe, public methods are not of course. There are two questions though: first, how can we ensure that these objects are never exposed by accident? second, how can we ensure that the JS built-in code is not calling public methods of these objects?
If JS Proxy was available in WebKit, we could wrap these objects as proxies in debug mode (using something like @assert(this. at myvar = Proxy(...)).
The proxies would be responsible to verify how these objects are accessed.

For objects that are exposed to user scripts, private methods of their prototype may not be available since the object prototype may have been changed. In that case, a solution is to do something like @Constructor.prototype. at method.@call. Far from perfect in terms of readability...
Again, for those objects, we could use Proxy to ensure they are safely accessed (@assert(stream = Proxy(stream...)).
We could also try sanitizing somehow these objects, for instance at the time promises are returned to streams from user scripts, or wrapping them.

Also, there are two different type of threats.
First a user script may disrupt an API by tweaking objects and prototypes.
This happens in the case where a JS built-in is expected to access a private method stored in the prototype.
If the user changes the prototype, the private method will not be available, thus breaking the functionality.
This is not a very good story but this is not too evil really.

Second, a user script may get access to data that should not be visible to user scripts.
This may happen for instance if an object is using a public method, the object or its prototype being accidentally exposed to user scripts. This is really bad.
To limit the second threat, using private methods should be recommended and conversely, using public methods should be discouraged in JS built-ins, even if the object/prototype is not supposed to get exposed.
Access to public methods stored in prototypes is particularly problematic since if one object is exposed, its prototype will also be exposed and this may end-up leaking information for all objects related to that prototype.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151124/86c447fb/attachment.html>