cross site scripting

**Ivo** · Jul 23 '05, 09:37 AM

Re: cross site scripting

"Andy Fish" wrote[color=blue]
> I found that by including a javascript file in the main window, this can[/color]
be[color=blue]
> called from one of the iframes and can manipulate the other iframes.
> However, if the iframe the user clicks in is hosted on a different server
> from the one owning the javascript, it cannot execute it. This will[/color]
clearly[color=blue]
> be the case in my scenario. Javascript running in one iframe cannot access[/color]
a[color=blue]
> different separate iframe even if it is on the same server.
>
> I guess this is to prevent XSS attacks.[/color]

Yes.
[color=blue]
> In this case, I don't want to update
> anything in the customer's window, but I want to be able to "own" several
> iframes and have them talk to each other.
>
> If anyone understands what I'm trying to achieve here, any ideas would be
> appreviated. Second best would be a definitive statement that it's
> impossible.[/color]

It 's impossible. Definitely. All participating frames, framesets, top,
parents, children and what-have-you must be from the same domain. That is
the part between the double slash and first next slash must be the same.
This rule is very scrict, I believe that even

Example Domain

http://www.example.com/

and

Example Domain

http://example.com/

are not able to talk to eachother .
Sorry. Look for ways not utilizing a multitude of iframes, but perhaps
update an image if you want to invoke a serverside process, such as
form.asp.png?cl ient=ABC&item=c ode1&quantity=2 . Another solution that comes
to mind is to create a popup window with script in your user's page that
points to a frameset on your own site so all frames at least in that window
are from the same domain.
Ivo

**Andy Fish** · Jul 23 '05, 09:37 AM

Re: cross site scripting

Thanks for the quick reply

I was looking for a way to give the customer more control over how my
functionality was presented on their site.

However, it looks like I will just have to put it all in one box that they
can embed as a single frame or iframe

Andy

"Ivo" <no@thank.you > wrote in message
news:406d2f9b$0 $24454$18b6e80@ news.wanadoo.nl ...[color=blue]
> "Andy Fish" wrote[color=green]
> > I found that by including a javascript file in the main window, this can[/color]
> be[color=green]
> > called from one of the iframes and can manipulate the other iframes.
> > However, if the iframe the user clicks in is hosted on a different[/color][/color]
server[color=blue][color=green]
> > from the one owning the javascript, it cannot execute it. This will[/color]
> clearly[color=green]
> > be the case in my scenario. Javascript running in one iframe cannot[/color][/color]
access[color=blue]
> a[color=green]
> > different separate iframe even if it is on the same server.
> >
> > I guess this is to prevent XSS attacks.[/color]
>
> Yes.
>[color=green]
> > In this case, I don't want to update
> > anything in the customer's window, but I want to be able to "own"[/color][/color]
several[color=blue][color=green]
> > iframes and have them talk to each other.
> >
> > If anyone understands what I'm trying to achieve here, any ideas would[/color][/color]
be[color=blue][color=green]
> > appreviated. Second best would be a definitive statement that it's
> > impossible.[/color]
>
> It 's impossible. Definitely. All participating frames, framesets, top,
> parents, children and what-have-you must be from the same domain. That is
> the part between the double slash and first next slash must be the same.
> This rule is very scrict, I believe that even
> http://www.example.com/
> and
> http://example.com/
> are not able to talk to eachother .
> Sorry. Look for ways not utilizing a multitude of iframes, but perhaps
> update an image if you want to invoke a serverside process, such as
> form.asp.png?cl ient=ABC&item=c ode1&quantity=2 . Another solution that comes
> to mind is to create a popup window with script in your user's page that
> points to a frameset on your own site so all frames at least in that[/color]
window[color=blue]
> are from the same domain.
> Ivo
>
>[/color]

**Richard Cornford** · Jul 23 '05, 09:37 AM

Re: cross site scripting

Ivo wrote:
<snip>[color=blue]
> It 's impossible. Definitely.[/color]

I agree.
[color=blue]
> All participating frames, framesets,
> top, parents, children and what-have-you must be from the same
> domain. That is the part between the double slash and first next
> slash must be the same. This rule is very scrict,
> I believe that even
> http://www.example.com/
> and
> http://example.com/
> are not able to talk to eachother .[/color]
<snip>

That is by default, but those two examples could use the -
document.domain - property to allow them to communicate. But between
http://example.com (and sub domains) and http://notExampe.com (and its
sub domains) communication is out of the question (no workaround and no
exceptions except for serious bugs that can be expected to be rapidly
fixed once identified).

The problem is that the IFRAMEs would be leafs in a tree structure in
which everything towards the root is inaccessible for security reasons,
and any javascript communication would have to be via something towards
the root.

The only common point through which the IFRAMEs could communicate would
be the server that they came from. Which would be a nightmare to
implement and orchestrate and probably dependent on some limited (on the
client) technology like ActiveX or Java.

Richard.

cross site scripting

cross site scripting

Comment

Comment

Comment