By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,225 Members | 2,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,225 IT Pros & Developers. It's quick & easy.

Cross domain iframe access

P: n/a
Lee
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/libr...28(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-c...n-with-iframes
who's right? any other ideas on how to do it?

thanks very much for _any_ idea
Lior
Jun 27 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
VK
On May 21, 6:02 am, Lee <liormessin...@gmail.comwrote:
According to this MSDN article,http://msdn.microsoft.com/en-us/libr...28(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.
Jun 27 '08 #2

P: n/a
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/libr...28(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
Jun 27 '08 #3

P: n/a
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
Jun 27 '08 #4

P: n/a
VK
On May 21, 3:22 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
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.
Jun 27 '08 #5

P: n/a
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, <f8*******************@news.demon.co.uk>
Jun 27 '08 #6

P: n/a
VK
On May 21, 10:41 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
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);
Jun 27 '08 #7

P: n/a
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, <f8*******************@news.demon.co.uk>
Jun 27 '08 #8

P: n/a
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.

Jun 27 '08 #9

P: n/a
VK
On May 22, 1:20 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
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.
Jun 27 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.