On Thu, Jul 18, 2013 at 4:04 AM, Benjamin Poulain <benja...@webkit.org>wrote:
> On Wed, Jul 17, 2013 at 5:54 AM, Jimmie Lin <jimmie....@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 tried using const to make it read only - but this is not what I am
exactly wanting. I want to prevent all frame to parent access that isn't
done through the restricted API I am providing the frame with. I'm running
potentially untrusted code so blocking out the .top property seems to be
the only solution.
>
>> 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.
>
Got it! I don't see any other potential solution to my problem though. I
understand the difficulty of maintaining a custom build of WebKit once I
change standard APIs, but are there any other solutions that may possibly
allow me to accomplish this?
>
> Benjamin
>
Thanks for your help!
- Jimmie Lin
_______________________________________________
webkit-help mailing list
webkit-help@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-help
