Cross domain iframe access

Discussion in 'Javascript' started by Lee, May 21, 2008.

  1. Lee

    Lee Guest

    Hi all,

    We need to create a page where we detect the finish of a game that's
    hosted on another site. We thought of doing it with frames, where we
    would put the game in an iframe that is contained in our page. All we
    need to do is to READ the location.href of that iframe (which is
    again, from anohter domain, not our domain) - but we can't!

    According to this MSDN article, http://msdn.microsoft.com/en-us/library/ms533028(VS.85).aspx
    "...document.location.href Property can be set to navigate, but cannot
    be read...."
    It's impossible.
    BUT: the 3rd law of this article here says we CAN do it
    http://softwareas.com/cross-domain-communication-with-iframes


    who's right? any other ideas on how to do it?

    thanks very much for _any_ idea
    Lior
    Lee, May 21, 2008
    #1
    1. Advertising

  2. Lee

    VK Guest

    On May 21, 6:02 am, Lee <> wrote:
    > According to this MSDN article,http://msdn.microsoft.com/en-us/library/ms533028(VS.85).aspx
    > "...document.location.href Property can be set to navigate, but cannot
    > be read...."
    > It's impossible.


    Right.

    > BUT: the 3rd law of this article here says we CAN do ithttp://softwareas.com/cross-domain-communication-with-iframes
    >
    > who's right?


    MSDN. The "3rd law" of softwareas.com is a clueless b.s. to disregard.

    It is an often excitement "how come reading back location I set by
    myself can be a cross-domain security violation?!?" so maybe I should
    explain:

    1) Page A from example.com has (i)frame with page B in it from
    example.net
    2) Page A sets location.href of B to say
    example.net?query=AbCdEfGhIgKlMn
    3) In response example.net makes redirect so B has resulting URL
    example.net?response=OpQrStUvWyXz
    4) Page A reads the URL and processing the response

    Cross-domain lock is bypassed.

    There are more sophisticated and malicious implementations of this
    technique but the core idea is here. This is why such security hole is
    found and locked longest time ago.

    > any other ideas on how to do it?


    You didn't specify what kind of game is that: Javascript/DOM, Flash,
    Silverlight, Java ?

    If for instance Javascript/DOM then:
    1) get the author's permission to host the game on your page
    2) use a server-side content grabber to serve the game into iframe
    from your own domain.
    VK, May 21, 2008
    #2
    1. Advertising

  3. Lee wrote:
    > We need to create a page where we detect the finish of a game that's
    > hosted on another site. We thought of doing it with frames, where we
    > would put the game in an iframe that is contained in our page. All we
    > need to do is to READ the location.href of that iframe (which is
    > again, from anohter domain, not our domain) - but we can't!
    >
    > According to this MSDN article, http://msdn.microsoft.com/en-us/library/ms533028(VS.85).aspx
    > "...document.location.href Property can be set to navigate, but cannot
    > be read...."
    > It's impossible.


    document.location is deprecated since more than 11 years ago, when it was
    still part of the programming language, JavaScript 1.1; window.location
    should be used instead. However, although window.location is an object, it
    can also be accessed as a property and, in contrast to window.location.href,
    this property is not tainted, i.e. not subject to the Same Origin Policy
    (apparently the property has a getter that is used then). So you can use it
    to determine the URI of the iframe content even though its domain is different.

    http://docs.sun.com/source/816-6409-10/sec.htm#1015705
    http://docs.sun.com/source/816-6409-10/sec.htm#1021266

    Ignoring "Often Wrong" VK prevents you from having to do even more
    unlearning later. The record shows.

    The relevance of PHP to this is exactly zero. Don't crosspost to Usenet and
    newsgroups that only exist in Google's archive. Because of this an its
    flawed interface, it is a good idea to avoid Google Groups *for posting*,
    and to use a decent news server and newsreader application instead. Try
    Mozilla Thunderbird or KNode.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, May 21, 2008
    #3
  4. Lee

    VK Guest

    On May 21, 12:33 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > However, although window.location is an object, it
    > can also be accessed as a property and, in contrast to window.location.href,
    > this property is not tainted, i.e. not subject to the Same Origin Policy


    Pardon my French, but are you really such an ignorant idiot or just
    getting some perverted pleasure of pretending to be such?

    It was clearly explained in my post why reading location is a big
    security risk and locked back to NN3/IE3 times - yet you posting this
    nonsense.

    btw besides the regular irritation you are caused a paid time loss for
    emergency check for the prominent browsers. Sure I am not claiming
    money back - but you own me now 100 "idiot" calls on you with I'll try
    to use wisely :) :-|

    ///////////

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <html lang="en-US">
    <head>
    <meta http-equiv="Content-type"
    content="text/html; charset=iso-8859-1">
    <title>Object Walker</title>
    <script type="text/javascript">
    function test() {

    var loc = '';

    var win = self.frames['frame01'];

    // trying to read the original URL

    try {
    loc = win.location.href;
    }
    catch(e) {
    window.alert(e.message || 'Unknown error');
    }
    try {
    loc = win.document.location.href;
    }
    catch(e) {
    window.alert(e.message || 'Unknown error');
    }

    win.location = 'http://www.example.com/index.html?foo=bar';

    // trying to read the new URL

    try {
    loc = win.location.href;
    }
    catch(e) {
    window.alert(e.message || 'Unknown error');
    }
    try {
    loc = win.document.location.href;
    }
    catch(e) {
    window.alert(e.message || 'Unknown error');
    }

    }

    function init() {
    test();
    }
    function releaseContextAndInit() {
    window.setTimeout('init()',10);
    }
    window.onload = releaseContextAndInit;
    </script>
    </head>
    <body>
    <iframe name="frame01"
    src="http://www.example.com/index.html"></iframe>
    </body>
    </html>
    VK, May 21, 2008
    #4
  5. VK wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> However, although window.location is an object, it
    >> can also be accessed as a property and, in contrast to window.location.href,
    >> this property is not tainted, i.e. not subject to the Same Origin Policy

    >
    > Pardon my French, but are you really such an ignorant idiot or just
    > getting some perverted pleasure of pretending to be such?


    Pot, kettle, black.

    > It was clearly explained in my post why reading location is a big
    > security risk and locked back to NN3/IE3 times - yet you posting this
    > nonsense.


    You have yet to explain what you meant, or rather what you assume to be true.

    > btw besides the regular irritation you are caused a paid time loss for
    > emergency check for the prominent browsers.


    If you do not know English well enough, please refrain from using English
    idioms or other advanced English vocabulary. Nothing good is being done by
    your posting such gibberish.

    > [...]
    > try {
    > loc = win.location.href;
    > }
    > catch(e) {
    > window.alert(e.message || 'Unknown error');
    > }
    > try {
    > loc = win.document.location.href;
    > }
    > catch(e) {
    > window.alert(e.message || 'Unknown error');
    > }


    I have said, and what can be assumed from your test code as well you have
    yet to understand, that reading window.location (here:
    window.frames["..."].location) directly, in contrast to reading
    window.location.href (here: window.frames["..."].location.href or the
    deprecated window.frames["..."].document.location.href property), is not
    subject to the Same Origin Policy and to the restrictions it imposes.

    I don't see how there could be a security risk involved in reading that
    property to determine if the embedded game -- it's only about a *game* after
    all -- was finished. ISTM you have not read the OP thoroughly enough or
    did not understand it properly.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, May 21, 2008
    #5
  6. Lee

    VK Guest

    On May 21, 3:22 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > I have said, and what can be assumed from your test code as well you have
    > yet to understand, that reading window.location (here:
    > window.frames["..."].location) directly, in contrast to reading
    > window.location.href (here: window.frames["..."].location.href or the
    > deprecated window.frames["..."].document.location.href property), is not
    > subject to the Same Origin Policy and to the restrictions it imposes.


    idiot! (99 remains :)

    did you try it before scaring people? did you actually try to read
    frameobj.location, frameobj['location']?
    if on any of your configurations it gives you anything other than
    security exception or null or undefined as it must: don't you dare to
    proudly report your proof case here: run to the bug forum of sorry
    idiots who produced that monster so they could fix it a.s.a.p. Lucky
    99.99 of all UAs including all I am anyhow concerned about are acting
    properly.

    > I don't see how there could be a security risk involved
    > in reading that property to determine if the embedded game
    > it's only about a *game* after all


    idiot! (98 remaining :)

    "Only a game" or someone's BankOfAmerica bank account or web-mail
    interface. Some no-names institutions had big troubles out of this
    "innocent extra feature" way long ago.

    Say in one 1px frame named "goptcha":

    function goptcha() {
    self.parent.frames['x'].
    document.forms[0].
    elements['data'].value = self.parent.
    frames['user'].location.href;
    self.parent.frames['x'].
    document.forms[0].submit();
    setTimeout("goptcha()",10000);
    }

    And the basic frame structure something like:

    <frameset rows="1,*" border="0">
    <frameset cols="50%,*" border="0">
    <frame name="goptcha" src="goptcha.html">
    <frame name="x" src="form.html">
    </frameset>
    <frame name="user" src="http://www.example.com">
    </frameset>

    Spend some time thinking of possible consequences of the above. Now
    add here modern x-domain tools like <script>-implants or JSONet, now
    add here iframe - so in total no need to drag anyone first into a
    specially crafted frameset. Now spend some time for thinking - and get
    lucky that was discovered and fixed before the modern DOM tools.
    VK, May 21, 2008
    #6
  7. VK wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> I have said, and what can be assumed from your test code as well you have
    >> yet to understand, that reading window.location (here:
    >> window.frames["..."].location) directly, in contrast to reading
    >> window.location.href (here: window.frames["..."].location.href or the
    >> deprecated window.frames["..."].document.location.href property), is not
    >> subject to the Same Origin Policy and to the restrictions it imposes.

    >
    > idiot! (99 remains :)
    >
    > did you try it before scaring people?


    Pot, kettle, black. I was obviously not scaring anyone. In fact, I have
    provided a working solution to a given problem while you indulged yourself
    in long-winded beside-the-point FUD instead.

    > did you actually try to read frameobj.location, frameobj['location']?


    Yes, I did. It worked fine as it was supposed to.

    > if on any of your configurations it gives you anything other than
    > security exception or null or undefined as it must:


    No, it does not need to. You have yet to show a single case where reading
    back this well-defined string value of window.frames["..."].location
    (remember, _not_ window.frames["..."].location.href) would be impossible or
    would pose a considerable security risk *in itself*. Especially, your
    posting and example code did not provide any substantial argument to that end.

    I would like to remind you again that the OP was not trying to use the
    string value for anything else but to determine whether the application on
    the other end had finished or not. They are in control of the document that
    embeds the game, not vice-versa. It is a pity that you still cannot see that.

    Obviously now, you have failed to understand or you have completely
    misunderstood the OP. Calling other people names does not change that, but
    only proves your wannabe status yet again. I strongly suggest you read the
    OP again, thoroughly, before you post your next followup. And I think in
    that followup an apology is in order.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, May 21, 2008
    #7
  8. Thomas 'PointedEars' Lahn wrote:
    > VK wrote:
    >> did you actually try to read frameobj.location, frameobj['location']?

    >
    > Yes, I did. It worked fine as it was supposed to.
    >
    >> if on any of your configurations it gives you anything other than
    >> security exception or null or undefined as it must:

    >
    > No, it does not need to. You have yet to show a single case where reading
    > back this well-defined string value of window.frames["..."].location
    > (remember, _not_ window.frames["..."].location.href) would be impossible


    I am afraid I have to show this myself. Curious. MSHTML, Opera and WebKit
    do not allow to read back the `location' string value of an iframe Window
    object in any case. Gecko (which I have tested with at first) only allows
    it when the embedding site is at localhost (where I have tested which was
    obviously too superficial a test).

    > or would pose a considerable security risk *in itself*. Especially, your
    > posting and example code did not provide any substantial argument to that end.


    However, I can still not see that.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, May 21, 2008
    #8
  9. Lee

    VK Guest

    On May 21, 10:41 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > I am afraid I have to show this myself. Curious. MSHTML, Opera and WebKit
    > do not allow to read back the `location' string value of an iframe Window
    > object in any case.


    Of course. See my latest post with an exploit sample. Similar code +
    some human factor usage to bring people to the exploit page - and one
    hugely popular in mid-90's web mail service and some popular e-
    commerce services got some big time troubles.
    See my first post with x-domain exploit.

    A child of peaceful times you are... I don't mean your age which I
    don't know - I mean Browser Wars paranoiac thinking one need to have
    to see the consequences.

    It is not a call to "cease fire" or something - but do you want to get
    my remained 98 credits signed off? :) Find the exploit. It caused a
    huge damage back in 95 (96?) so now any browser allows to set "type"
    property of dynamically created form controls only once: and some
    browsers do not allow it at all so some tricky workarounds are needed.

    So what is so potentially highly dangerous is say:

    var elm = document.createElement('INPUT');
    elm.type = 'TEXT';
    elm.onclick = myFunction;
    myContainer.appendChild(elm);
    VK, May 21, 2008
    #9
  10. VK wrote:
    > It is not a call to "cease fire" or something -


    ROTFL! As if you of all people were in a position to teach me or any other
    regular here anything.

    > but do you want to get my remained 98 credits signed off? :)


    I have no intention to satisfy your curiosity, nor do I put any value on any
    credits you could ever grant. As for your bill here, you are still very
    much in the newsgroup's debt, not vice-versa.

    > Find the exploit. It caused a huge damage back in 95 (96?)


    Is there any proof to back up this fascinating fairytale of yours?

    > so now any browser allows to set "type" property of dynamically created
    > form controls only once: and some browsers do not allow it at all so some
    > tricky workarounds are needed.


    This is simply untrue. For example, Fx 2, Opera 9.27, and Safari 3.1 do
    support a second and subsequent assignment to the `type' property. Of all
    the user agents tested, which include those mentioned, only MSHTML refuses
    to change the type. And I have tested it more thoroughly this time. Here
    is the test code:

    var inp = document.createElement("input");
    inp.type = "text";
    inp.value = "foo";
    document.body.appendChild(inp);
    window.alert("Now it is a text input.");
    inp.type = "password";
    window.alert("Now it is a password input.");
    inp.type = "checkbox";
    window.alert("Now it is a checkbox.");
    inp.type = "radio";
    window.alert("Now it is a radio button.");
    inp.type = "submit";
    window.alert("Now it is a submit button.");
    inp.type = "reset";
    window.alert("Now it is a reset button.");
    inp.type = "file";
    window.alert("Now it is a file input.");
    inp.type = "hidden";
    window.alert("Now it is a hidden input.");
    inp.type = "image";
    window.alert("Now it is a graphical submit button.");
    inp.type = "button";
    window.alert("Now it is a general button.");

    What can be observed, however, is that all UAs but IE reset the value of the
    control when the type is changed to "file", thus preventing abuse that would
    be possible if one could set the value with a non-file control and then use
    it to submit any local file after turning the control into a file input.
    Obviously this is the more sensible approach in solving this problem than to
    categorically forbid any change of type.

    > So what is so potentially highly dangerous is say:
    >
    > var elm = document.createElement('INPUT');
    > elm.type = 'TEXT';
    > elm.onclick = myFunction;
    > myContainer.appendChild(elm);


    I presume you actually think only you possess the required wisdom for the
    explanation.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, May 21, 2008
    #10
  11. Thomas 'PointedEars' Lahn wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> VK wrote:
    >>> did you actually try to read frameobj.location,
    >>> frameobj['location']?

    >>
    >> Yes, I did. It worked fine as it was supposed to.
    >>
    >>> if on any of your configurations it gives you anything other than
    >>> security exception or null or undefined as it must:

    >>
    >> No, it does not need to. You have yet to show a single case where
    >> reading back this well-defined string value of
    >> window.frames["..."].location
    >> (remember, _not_ window.frames["..."].location.href) would be
    >> impossible

    >
    > I am afraid I have to show this myself. Curious. MSHTML, Opera
    > and WebKit do not allow to read back the `location' string value
    > of an iframe Window object in any case. Gecko (which I have tested
    > with at first) only allows it when the embedding site is at localhost
    > (where I have tested which was obviously too superficial a test).

    <snip>
    Issues in type converting the location object into a string do not
    impact on the validity of your assertion that:-

    | I have said, ... , that reading window.location (here:
    | window.frames["..."].location) directly, in contrast to reading
    | window.location.href (here: window.frames["..."].location.href
    | or the deprecated window.frames["..."].document.location.href
    | property), is not subject to the Same Origin Policy and to the
    | restrictions it imposes.

    - because type conversion to a string implies an internal call to the
    object's - toString - method, and in just the same way as security
    restrictions may apply to the - href - property of the location object
    without the object itself being subject to the 'Same Origin Policy' the
    same can be true of the object's - toString - method. Such that any
    attempt to read the - toString - property, or if it can be read then to
    execute its value, may be the point at which a security exception is
    thrown.

    Other forms of direct access to the - location - object certainly can
    stand as a demonstration that reading its value is not subject to any
    security restrictions. For example, reading the value of non-existent
    property, such as:-

    frames[" ... "].location.dummy

    - results in the undefined value without throwing any exceptions on IE,
    Firefox and Opera. Resolving that whole property accessor successfully
    necessitates successful reading of the value of - frames[" ...
    "].location -, and interacting with the object that is its value
    (calling its internal [[Get]] method).

    Other test subject for the question of whether it is possible to
    directly access the value of a - location - object without security
    exceptions being thrown might be a - typeof - test, assigning the value
    to a local variable, or comparing the object with another object. If the
    location object were itself subject to these restrictions, any of those
    should be expected to throw an exception.

    A demonstration might be the following minimal HTML page. If reading the
    value of the - location - property of an IFRAME that contained a page
    from an different domain neither of the two alerts in the following code
    would be shown. But in reality both are shown when the browser is IE,
    Firefox or Opera (and very probably all others).

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
    Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <title></title>
    <script type="text/javascript">
    window.onload = function(){
    alert(
    'frames["test"].location.dummy = '+
    frames["test"].location.dummy
    ); // Expect "undefined".

    alert(
    'typeof frames["test"].location = '+
    (typeof frames["test"].location)
    );// Expect "object" (but possibly "function").
    };
    </script>
    </head>
    <body>
    <iframe src="http://www.google.com/" id="test" name="test"></iframe>
    </body>
    </html>

    Richard.
    Richard Cornford, May 21, 2008
    #11
  12. Lee

    VK Guest

    On May 22, 1:20 am, "Richard Cornford" <>
    wrote:
    > A demonstration might be the following minimal HTML page. If reading the
    > value of the - location - property of an IFRAME that contained a page
    > from an different domain neither of the two alerts in the following code
    > would be shown. But in reality both are shown when the browser is IE,
    > Firefox or Opera (and very probably all others).
    >
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
    > Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    > <html>
    > <head>
    > <title></title>
    > <script type="text/javascript">
    > window.onload = function(){
    > alert(
    > 'frames["test"].location.dummy = '+
    > frames["test"].location.dummy
    > ); // Expect "undefined".
    >
    > alert(
    > 'typeof frames["test"].location = '+
    > (typeof frames["test"].location)
    > );// Expect "object" (but possibly "function").};
    >
    > </script>
    > </head>
    > <body>
    > <iframe src="http://www.google.com/" id="test" name="test"></iframe>
    > </body>
    > </html>


    It is because for two reasons:
    1) applicable to Netscape and IE at the time if the events, it was an
    emergency security patch to do it anyhow but bulletproof yet quickly.
    2) at that time the idea of handled exceptions was in its very
    babyhood and "throw" even for programmers was first associated with
    stones or money :) rather than with some programming matters. While
    for Java it could have some small sense, throwing any kind of
    exceptions in an environment that didn't implement any mechanics for
    them would be silly.

    So instead a brute force interceptor was planted into property
    resolution chain:

    on PROPERTY_GET request reaching "location" point the real value is
    thrown away and set to undefined (later many producers decided what it
    is cleaner to set it to null instead, so this is what you get in say
    Gecko builds).

    on PROPERTY_SET request reaching "location" point the value to set is
    thrown away but PROPERTY_SET_OK reported back. A bit confusing but has
    sense as one doesn't break code execution unless it is indeed
    necessary to break the code execution. This way one can set any
    properties to window.location and the program will keep working as
    long as she doesn't try to read them back.

    The younger generation of browsers simply emulates this behavior
    because it is like DOM 0 - survival compatibility minimum first,
    anything else after.
    VK, May 21, 2008
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    3,444
    CyberOwl
    Sep 7, 2009
  2. Andrew Thompson
    Replies:
    2
    Views:
    583
    Knute Johnson
    Aug 18, 2008
  3. Replies:
    0
    Views:
    488
  4. Daedalous
    Replies:
    3
    Views:
    664
    Daedalous
    Jan 16, 2004
  5. Cindy Lee
    Replies:
    1
    Views:
    411
    Randy Webb
    May 7, 2004
Loading...

Share This Page