Re: MSIEv6 % encoding causes a problem again

["jelmer" <jkuperus () xs4all nl>]

on the border of stating the obvious %5c (backslash) will also work

Aside from that point, you mention the pull's bug as an example of the
consequences however this one would appear to be slightly less serious as
the file protocol doesn't allow authentication of the sort

file://jelmer:password@c://test.txt

thus local files can not be read, you can't execute programs using the
object tag etc

It is pretty serious though, what remains is universal cross site scripting
witch implies you can read the cookies of any domain or can make it look as
if you are browsing a trusted site however the content is under your
control. Thus you can create fake login screens etc without raising
suspicion

--
  jelmer

----- Original Message -----
From: "Dave Ahmad" <da () securityfocus com>
To: "Liu Die Yu" <liudieyuinchina () yahoo com cn>
Sent: Wednesday, September 04, 2002 6:32 PM
Subject: Re: MSIEv6 % encoding causes a problem again


> I am surprised that nobody has yet commented on this rather serious issue.
> It appears that MSIE fails to properly extract the correct domain from the
> URI string in the parent window when evaluating it against the child
> domain to determine whether access is to be permitted.  This seems to be
> because of the inclusion of "%2f" (HTTP encoded slash character) in a
> URI-specified HTTP username.  I am guessing that the URI parser within
> Explorer decides it has the complete domain once it sees a slash
> without taking into consideration that it could be within a
username/password.
> Consequently, the HTTP username "www.yahoo.com" matches the domain of the
> child window ( window.open("www.yahoo.com") ) and access is granted.  This
> violates the "same-origin policy" and has numerous security implications.
>
> In effect, this is similar to other issues found in explorer recently
> (most memorably, that discovered by thePull -
http://online.securityfocus.com/bid/3721).
> Mitigating factor:
>
> The attacker must lure the victim to a page where the URI in the location
> bar includes the target website as the username.  Not that the victim
> has much time to do anything about it, this may look suspicious
> (though there could be a way to set the location property, or whichever
> is used, to the target website while keeping the value visible in the
> location bar "normal").
>
> David Ahmad
> Symantec
> http://www.symantec.com/
>
> On 3 Sep 2002, Liu Die Yu wrote:
>
> > it's about cross-site scripting at MSIEv6 client side using % encoding,
> > but not the same as the one by PeaceFire.org which doesn't work on my
PC.
> > [tested]MSIEv6(CN version)
> > {IEXPLORE.EXE file version: 6.0.2600.0000}
> > {MSHTML.DLL file version: 6.00.2600.0000}
> >
> > [demo]
> > at
> > http://www16.brinkster.com/liudieyu/2FforMSIE/2FforMSIE-MyPage.htm
> > or
> > clik.to/liudieyu ==> 2FforMSIE-MyPage section.
> >
> > [exp]
> > %?? in URL is decoded when IE caculates the domain, but not decoded
while
> > downloading a page.
> > so
> > [CODE.URL]http://www.yahoo.com%2F () clik to/liudieyu
> > ( 2F=hex$(asc('/')) )
> > leads to clik.to/liudieyu instead of www.yahoo.com, and the domain of it
> > www.yahoo.com for IE
> >
> > Very simple, that's all.
> >
> > [contact]
> > liudieyuinchina () yahoo com cn