[webkit-help] Customizing WebKit to disable .top property in frames (Unidirectional Parent -> Frame access)

Benjamin Poulain benjamin at webkit.org
Wed Jul 17 13:04:27 PDT 2013

On Wed, Jul 17, 2013 at 5:54 AM, Jimmie Lin <jimmie.lin at gmail.com> wrote:

> I am developing a custom WebKit-based application which has a web
> interface providing a javascript API (stored in a variable called "System")
> to several "child interfaces" in frames. I am providing the frames a
> stripped down version of the API (stored in "System.User") using code that
> looks like this:
> var frame = document.getElementById("frame");
> frame.contentWindow.System = System.User;
> Now, I do not want the child frame to be able to do something like
> "document.window.top.System = null" and destroy the whole thing running
> above. However I cannot turn on the "sandbox" iframe feature as that would
> prevent me from providing the frame with its own copy of the API in the
> first place.

If your goal is simply to prevent someone from replacing your "System"
property, you should just make it read only.

> I have attemped to do the following:
> frame.contentWindow.parent = null;
> frame.contentWindow.top = null;
> But this does not work, as the .top property is a read-only one and cannot
> be overwritten. Other methods using just Javascript to solve this problem
> proved not possible. Since I can deploy the application using a custom
> build of WebKit, where in the source should I look into modifying to
> totally remove the .top property in frames?
> I want the frame to be able to communicate with the parent strictly by
> using the System object in it, but full access to the frame should be
> completely unidirectional.

If you want to remove the top property from the exposed API, just remove it
from the bindings (DOMWindow.idl). But I think it is a bad idea; altering
standard APIs always leads to problem down the road.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20130717/c69c9b3f/attachment.html>

More information about the webkit-help mailing list