PRB: "Permission Denied" When Scripting Across Frames

Last reviewed: March 5, 1998
Article ID: Q167796
The information in this article applies to:
  • Microsoft Internet Explorer (Programming), versions 4.0, 4.01
  • Internet Client SDK, version 4.0, 4.01

SYMPTOMS

Script code that attempts to access a script or object in a different frame may get the following script error message:

    Permission denied: 'Parent.RemoteFrame.RemoteObject'

CAUSE

Internet Explorer 4.0 implements cross-frame security. A script or object in one frame is not allowed to access scripts or objects in another frame when the documents referenced by the frames' SRC attribute specify Web servers in different second-level domains. This corresponds to the "domain- name.XXX" portion of the full server name syntax "server.domain-name.XXX".

The Internet Explorer 4.0 Dynamic HTML object model allows a certain subset of safe actions to be scripted. For example, the window.location property of a remote server's frame can be set to allow navigation, but it cannot be read to prevent one frame from snooping on the contents of another frame.

For example, it is valid for a document retrieved from "http://test.microsoft.com" to manipulate another document retrieved from "http://test.microsoft.com." It is not valid for a document retrieved from "http://server1.some-domain-name.org" to manipulate a document located retrieved from "http://server2" or "http://server3.microsoft.com."

The intention of cross-frame security is to prevent one Web page designer from potentially misusing or snooping on the trusted objects authored by a different Web page designer. Only those pages hosted in the same domain can be trusted to safely script the contents of a particular page. This should also prevent unwanted communication between documents on opposite sides of a corporate firewall.

Please refer to the Internet Client SDK for more information.

RESOLUTION

To prevent this error, documents that interact with each other must be hosted by servers on the same domain.

To allow two documents hosted on the same second-level domain to interact, both documents must set the document.domain property to their shared second- level domain. For example, one document on "http://example.microsoft.com" could script and access another document on "http://test.microsoft.com" if both documents used the following line of script code:

   <SCRIPT LANGUAGE="VBScript">
       document.domain = "microsoft.com"
   </SCRIPT>

STATUS

This behavior is by design.

MORE INFORMATION

For example, given the following FRAMESET:

   <FRAMESET COLS="50%, *" FRAMEBORDER=1>
      <FRAME SRC="http://server1/server1.html" ID="Server1Frame">
      <FRAME SRC="http://server2/server2.html" ID="Server2Frame">
   </FRAMESET>

Script in the "Server1Frame" frame is not permitted to access script or objects in the "Server2Frame" frame, and vice versa.

The following example script code in server1.html causes the "Permission Denied" error, given that RemoteTextBox is an object created on the server2.html document:

   <!-- From server1.html -->
   <SCRIPT LANGUAGE="VBScript">
       Sub CommandButtonLocal_Click()
           Parent.Server2Frame.RemoteTextBox.Text = "Changed Text"
                  'Server2Frame has SRC on different server
       end sub
   </SCRIPT>

Cross-Frame Security uses the concept of a "security context" to make cross- frame scripting decisions. Security context takes into account the protocol, domain, and zone of Internet documents. Any differences in these three between the document containing the script and the document in another frame or window that the script is trying to manipulate causes a cross-frame security violation. For example, HTTP documents cannot script HTTPS documents, and sites in the Restricted Sites zone cannot script sites in the Local intranet zone.

Internet Explorer 4.0 ultimately appeals to the Security Manager when script attempts to access another document. Technically, Internet Explorer 4.0 uses the IInternetSecurityManager::GetSecurityId() function to help it make security context decisions. The security identification returned must match exactly for both URLs in a cross-frame situation. Please refer to the Internet Client SDK documentation for more information on the Internet Security Manager.

REFERENCES

  • Internet Client SDK: Dynamic HTML; Document Object Model; Cross-Frame Scripting and Security
  • RFC 1591: "Domain Name System Structure and Delegation"
  • RFC 1034: "DOMAIN NAMES - CONCEPTS AND FACILITIES"
  • Internet Client SDK: Internet Tools & Technologies; Monikers, URLs, Security Zones, and Pluggable Protocols

Keywords          : AXSDKIESripting kbprb
Version           : 4.0
Platform          : WINDOWS
Issue type        : kbprb


================================================================================


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: March 5, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.