JavaScript's "Same Origin Policy" (XWT Foundation Security Advisory)

[Koos Vriezen]

On Thu, 1 Aug 2002, Till Krech wrote:

> On Wednesday 31 July 2002 14:53, Koos Vriezen wrote:
> > On Wed, 31 Jul 2002, Vadim Plessky wrote:
> > > _________________________________________________________________________
> > >_____ Abstract
> > >
> > > The following exploit constitutes a security flaw in JavaScript's
> > > "Same Origin Policy" (SOP) [1]. Please note that this is *not* the
> > > IE-specific flaw reported in Februrary [2].
> > >
> > > The exploit allows an attacker to use any JavaScript-enabled web
> > > browser behind a firewall to retrive content from (HTTP GET) and
> > > interact with (HTTP <form/> POST) any HTTP server behind the
> > > firewall. If the client in use is Microsoft Internet Explorer 5.0+,
> > > Mozilla, or Netscape 6.2+, the attacker can also make calls to SOAP or
> > > XML-RPC web services deployed behind the firewall.
> >
> > Is this really a JS flaw, or is there something with the DNS lookup wrong?
> > IMHO a DNS server should never respond with a private ip address, after
> > forwarding a request to a non-private DNS server.
> > Don't know if I can configure bind that way...
>
> I think, the trick is that you download a page from outside the firewall,
> which can then, with the locally running javascript, access ressources from
> the inner side. Think of a javascript filling a frame with content using
> otherframe.document.location.href="http://intranet/internal.html"
> and then reading out this frame (innerHTML or so) and send the content back to
> the server outside.
> The question is: can a javascript from one location (page from evil server)
> access the page/script/dom tree which stems from another location (intranet)?
> Without this possibility, the above would not work - what it shouldn't.

AFAIK khtml has this security check, but not on private/public ip ranges.

Koos