[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Re: Link Injection Redirection Attacks - Exploiting Google Chrome Design Flaw
- From: Berend-Jan Wever <berendjanwever@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Re: Link Injection Redirection Attacks - Exploiting Google Chrome Design Flaw
- Date: Wed, 6 Jan 2010 15:33:06 +0100
--0016361648ed600a68047c7fd656
Content-Type: text/plain; charset=ISO-8859-1
Hi Aditya,
I've marked that bug as a duplicate of the feature request I opened for you
earlier. I've taken the time to address some of the points in that report
and this one again:
> Every time this issue comes up, the point of status bar
> link interpretation is discussed which is simply one point of just
> showing the way links active in web page.
As mentioned before, the status bar in Chromium is considered to be part of
the webpage. The webpage can contain arbitrary content and the status bar
can as well. It is not designed to provide information on which to base
security decisions. *Reporting a spoofing vulnerability against the status
bar is pointless.*
> The web page input problem is
> always a case but the browser problems make it more adverse.
Links are intended to take the user to the URL specified by the webpage. The
browser cannot be blamed if the webpage provides a bad link. *This is not a
vulnerability or problem in Chromium.*
> I think this can clear the point. Its the same point which I am
> mentioning from long time. We just want that issues should be patched so
> that users can have better experience.
I have opened a feature request for code that tries to detect the type of
attack against webpages that you describe and warn the user. I have no data
to check, but it seems to me that everything from
the likelihood, success-rate, usefulness, severity to the impact of such
attacks is low. *I expect this is an edge case that is not worth addressing.
*
Cheers,
SkyLined
Berend-Jan Wever <berendjanwever@gmail.com>
http://skypher.com/SkyLined
On Wed, Jan 6, 2010 at 4:51 AM, Aditya K Sood <0kn0ck@secniche.org> wrote:
> Hi Berend-Jan
>
> Please find the respective responses
> > Repro steps:
> > 1) Some website do not sanitize user input correctly, such as the one
> > in your example, which allows things like XSS:
> > http://www.worksafenb.ca/redirect.asp?V=";'%20src=
> http://skypher.com/SkyLined/xss.js></SCRIPT><SCRIPT%20x='
> > http://www.worksafenb.ca/redirect.asp?V=*/
> </SCRIPT>"<SCRIPT>alert(document.cookie);/*
> > <
> http://www.worksafenb.ca/redirect.asp?V=*/%3C/SCRIPT%3E%22%3CSCRIPT%3Ealert%28document.cookie%29;/*
> >
> > 2) This may also allow the '@' character to be inserted into a link on
> > the site, which has special meaning in URLs, as described
> > in http://www.ietf.org/rfc/rfc1738.txt:
> > 3.1. Common Internet Scheme Syntax
> >
> > While the syntax for the rest of the URL may vary depending on the
> > particular scheme selected, URL schemes that involve the direct use
> > of an IP-based protocol to a specified host on the Internet use a
> > common syntax for the scheme-specific data:
> >
> > //<user>:<password>@<host>:<port>/<url-path>
> > 3) Because Chromium follows the RFC and parses the URL correctly, a
> > user that clicks on the link will be taken to the site specified by
> > the URL.
> >
> > As you can see, I unfortunately fail to understand why this is a
> > design flaw in Chromium. It seems to me that you are suggesting
> > that Chromium add a feature to mitigate this server-side problem by
> > ignoring the RFC and prevent all links with an @ sign in them from
> > working altogether like MSIE does or warn the user about such URLs
> > like Firefox does? I am obviously missing something here, maybe you
> > can elaborate even further?
> The point is not of implementation. URL/URI specification provided in
> the RFC is treated as standard benchmark but the point here is about the
> security check which is not implemented in Chrome. Every time this issue
> comes up, the point of status bar
> link interpretation is discussed which is simply one point of just
> showing the way links active in web page. The web page input problem is
> always a case but the browser problems make it more adverse.
> >
> > I don't want to take too much of your precious time as a researcher,
> > so I reported this feature request for you:
> > http://code.google.com/p/chromium/issues/detail?id=31625
> > You mentioned that you have reported this before but I couldn't find
> > any bugs relating to this:
> > http://code.google.com/p/chromium/issues/list?can=1&q=reporter:Adi.ZeroK
> > <
> http://code.google.com/p/chromium/issues/list?can=1&q=reporter:Adi.ZeroK&sort=-id&colspec=ID+Summary+Status+Modified+Type+Restrict+Pri+Mstone+Owner&x=mstone&y=area&cells=tiles
> >
> > Maybe you could find them and mark as duplicates of this bug yourself
> > (or the other way around)?
> I am not sure about the fact that you have not found that. It was
> reported on 28 November 2008 and the status was changed to "Wont Fix" by
> the team itself. You can have a look at:
>
> http://code.google.com/p/chromium/issues/detail?id=4739
>
> I think this can clear the point. Its the same point which I am
> mentioning from long time. We just want that issues should be patched so
> that users can have better experience.
>
> Kind Regards
> Aditya
>
> >
> > Thanks!
> >
> > SkyLined
> >
> >
> > Berend-Jan Wever <berendjanwever@gmail.com
> > <mailto:berendjanwever@gmail.com>>
> > http://skypher.com/SkyLined
> >
> >
> >
> > On Tue, Jan 5, 2010 at 3:02 PM, Aditya K Sood <0kn0ck@secniche.org
> > <mailto:0kn0ck@secniche.org>> wrote:
> >
> >
> > Hi
> >
> > Recently with an outcome of Owasp RC1 top 10 exploited vulnerability
> > list , redirection issues have already
> > made a mark in that. Even the WASC has included the URL abusing as
> one
> > of the stringent attacks.
> > Well to be ethical in this regard these are not the recent attacks
> but
> > are persisting from long time. The only
> > difference is the exploitation ratio has increased from bottom to
> top.
> > So that's the prime reason it has been
> > included in the web application security benchmarks. But the
> > projection
> > of redirection attacks is active now.
> >
> > This post is not about explaining the basics of redirection issues.
> It
> > is more about the design vulnerabilities
> > in browsers that can lead to potential persistent redirection
> > vulnerabilities. Web application security can be
> > hampered due to browser problems.
> >
> > Note: The base is to project the implications of browser inefficiency
> > and the ease in conducting web application attacks.
> >
> > Post:
> >
> http://zeroknock.blogspot.com/2010/01/link-injection-redirection-attacks.html
> >
> > Video: http://www.secniche.org/videos/google_chrome_link_inj.html
> >
> > Browsers need to take care of these issues.
> >
> > Regards
> > Aditya K Sood
> > http://www.secniche.org
> >
> >
>
>
--0016361648ed600a68047c7fd656
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hi Aditya,</div><div><br></div><div><div>I've marked that bug as a=
duplicate of the feature request I opened for you earlier. I've taken =
the time to address some of the points in that report and this one again:</=
div>
<div><br></div></div><div><span class=3D"Apple-style-span" style=3D"font-fa=
mily: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">>=
Every time this issue=A0comes up, the point of status bar<br>> link int=
erpretation is discussed which is simply one point of just<br>
> showing the way links active in web page.</span></div><div><span class=
=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font-size: 1=
3px; border-collapse: collapse; ">As mentioned before, the status bar in Ch=
romium is considered to be part of the webpage. The webpage can contain arb=
itrary content and the status bar can as well. It is not designed to provid=
e information on which to base security=A0decisions. <i>Reporting a spoofin=
g vulnerability against the status bar is pointless.</i></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><br></span></div><div><sp=
an class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font=
-size: 13px; border-collapse: collapse; ">> The web page input problem i=
s=A0<br>
> always a case but the browser problems make it more adverse.</span></d=
iv><div>Links are intended to take the user to the URL specified by the web=
page. The browser cannot be blamed if the webpage provides a bad link. <i>T=
his is not a vulnerability or problem in Chromium.</i></div>
<div><br></div><div><span class=3D"Apple-style-span" style=3D"font-family: =
arial, sans-serif; font-size: 13px; border-collapse: collapse; ">>=A0I t=
hink this can clear the point. Its the same point which I am<br>>=A0ment=
ioning from long time. We just want that issues should be patched so<br>
> that users can have better experience.</span></div><div>I have opened =
a feature request for code that tries to detect the type of attack against =
webpages that you describe and warn the user. I have no data to check, but =
it seems to me that everything from the=A0likelihood,=A0success-rate, usefu=
lness, severity to the impact=A0of such attacks is low.=A0<i>I expect this =
is an edge case that is not worth addressing.</i></div>
<div><br></div><div>Cheers,</div><div><br></div><div>SkyLined</div><div><br=
></div>Berend-Jan Wever <<a href=3D"mailto:berendjanwever@gmail.com"; tar=
get=3D"_blank">berendjanwever@gmail.com</a>><br><a href=3D"http://skyphe=
r.com/SkyLined" target=3D"_blank">http://skypher.com/SkyLined</a><br>
<br>
<br><br><div class=3D"gmail_quote">On Wed, Jan 6, 2010 at 4:51 AM, Aditya K=
Sood <span dir=3D"ltr"><<a href=3D"mailto:0kn0ck@secniche.org"; target=
=3D"_blank">0kn0ck@secniche.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Hi Berend-Jan<br>
<br>
Please find the respective responses<br>
<div>> Repro steps:<br>
> 1) Some website do not sanitize user input correctly, such as the one<=
br>
> in your example, which allows things like XSS:<br>
> <a href=3D"http://www.worksafenb.ca/redirect.asp?V=3D"; target=3D"_blan=
k">http://www.worksafenb.ca/redirect.asp?V=3D</a>"'%20src=3D<a hre=
f=3D"http://skypher.com/SkyLined/xss.js"; target=3D"_blank">http://skypher.c=
om/SkyLined/xss.js</a>></SCRIPT><SCRIPT%20x=3D'<br>
> <a href=3D"http://www.worksafenb.ca/redirect.asp?V=3D*/"; target=3D"_bl=
ank">http://www.worksafenb.ca/redirect.asp?V=3D*/</a></SCRIPT>"&=
lt;SCRIPT>alert(document.cookie);/*<br>
</div>> <<a href=3D"http://www.worksafenb.ca/redirect.asp?V=3D*/%3C/S=
CRIPT%3E%22%3CSCRIPT%3Ealert%28document.cookie%29;/*" target=3D"_blank">htt=
p://www.worksafenb.ca/redirect.asp?V=3D*/%3C/SCRIPT%3E%22%3CSCRIPT%3Ealert%=
28document.cookie%29;/*</a>><br>
<div>> 2) This may also allow the '@' character to be inserted i=
nto a link on<br>
> the site, which has special meaning in URLs, as described<br>
> in <a href=3D"http://www.ietf.org/rfc/rfc1738.txt"; target=3D"_blank">h=
ttp://www.ietf.org/rfc/rfc1738.txt</a>:<br>
> 3.1. Common Internet Scheme Syntax<br>
><br>
> =A0 =A0While the syntax for the rest of the URL may vary depending on =
the<br>
> =A0 =A0particular scheme selected, URL schemes that involve the direct=
use<br>
> =A0 =A0of an IP-based protocol to a specified host on the Internet use=
a<br>
> =A0 =A0common syntax for the scheme-specific data:<br>
><br>
> =A0 =A0 =A0 =A0 //<user>:<password>@<host>:<port&=
gt;/<url-path><br>
> 3) Because Chromium follows the RFC and parses the URL correctly, a<br=
>
> user that clicks on the link will be taken to the site specified by<br=
>
> the URL.<br>
><br>
> As you can see, I unfortunately fail to understand why this is a<br>
> design flaw in Chromium. It seems to me that you are suggesting<br>
> that Chromium add a feature to mitigate this server-side problem by<br=
>
> ignoring the RFC and prevent all links with an @ sign in them from<br>
> working altogether like MSIE does or warn the user about such URLs<br>
> like Firefox does? I am obviously missing something here, maybe you<br=
>
> can elaborate even further?<br>
</div>The point is not of implementation. URL/URI specification provided in=
<br>
the RFC is treated as standard benchmark but the point here is about the<br=
>
security check which is not implemented in Chrome. Every time this issue<br=
>
comes up, the point of status bar<br>
link interpretation is discussed which is simply one point of just<br>
showing the way links active in web page. The web page input problem is<br>
always a case but the browser problems make it more adverse.<br>
<div>><br>
> I don't want to take too much of your precious time as a researche=
r,<br>
> so I reported this feature request for you:<br>
> <a href=3D"http://code.google.com/p/chromium/issues/detail?id=3D31625"=
target=3D"_blank">http://code.google.com/p/chromium/issues/detail?id=3D316=
25</a><br>
> You mentioned that you have reported this before but I couldn't fi=
nd<br>
> any bugs relating to this:<br>
> <a href=3D"http://code.google.com/p/chromium/issues/list?can=3D1&q=
=3Dreporter:Adi.ZeroK" target=3D"_blank">http://code.google.com/p/chromium/=
issues/list?can=3D1&q=3Dreporter:Adi.ZeroK</a><br>
</div><div>> <<a href=3D"http://code.google.com/p/chromium/issues/lis=
t?can=3D1&q=3Dreporter:Adi.ZeroK&sort=3D-id&colspec=3DID+Summar=
y+Status+Modified+Type+Restrict+Pri+Mstone+Owner&x=3Dmstone&y=3Dare=
a&cells=3Dtiles" target=3D"_blank">http://code.google.com/p/chromium/is=
sues/list?can=3D1&q=3Dreporter:Adi.ZeroK&sort=3D-id&colspec=3DI=
D+Summary+Status+Modified+Type+Restrict+Pri+Mstone+Owner&x=3Dmstone&=
;y=3Darea&cells=3Dtiles</a>><br>
</div><div>> Maybe you could find them and mark as duplicates of this bu=
g yourself<br>
> (or the other way around)?<br>
</div>I am not sure about the fact that you have not found that. It was<br>
reported on 28 November 2008 and the status was changed to "Wont Fix&q=
uot; by<br>
the team itself. You can have a look at:<br>
<br>
<a href=3D"http://code.google.com/p/chromium/issues/detail?id=3D4739"; targe=
t=3D"_blank">http://code.google.com/p/chromium/issues/detail?id=3D4739</a><=
br>
<br>
I think this can clear the point. Its the same point which I am<br>
mentioning from long time. We just want that issues should be patched so<br=
>
that users can have better experience.<br>
<br>
Kind Regards<br>
Aditya<br>
<div><br>
><br>
> Thanks!<br>
><br>
> SkyLined<br>
><br>
><br>
> Berend-Jan Wever <<a href=3D"mailto:berendjanwever@gmail.com"; targe=
t=3D"_blank">berendjanwever@gmail.com</a><br>
</div>> <mailto:<a href=3D"mailto:berendjanwever@gmail.com"; target=3D=
"_blank">berendjanwever@gmail.com</a>>><br>
<div>> <a href=3D"http://skypher.com/SkyLined"; target=3D"_blank">http://=
skypher.com/SkyLined</a><br>
><br>
><br>
><br>
> On Tue, Jan 5, 2010 at 3:02 PM, Aditya K Sood <<a href=3D"mailto:0k=
n0ck@secniche.org" target=3D"_blank">0kn0ck@secniche.org</a><br>
</div><div><div></div><div>> <mailto:<a href=3D"mailto:0kn0ck@secnich=
e.org" target=3D"_blank">0kn0ck@secniche.org</a>>> wrote:<br>
><br>
><br>
> =A0 =A0 Hi<br>
><br>
> =A0 =A0 Recently with an outcome of Owasp RC1 top 10 exploited vulnera=
bility<br>
> =A0 =A0 list , redirection issues have already<br>
> =A0 =A0 made a mark in that. Even the WASC has included the URL abusin=
g as one<br>
> =A0 =A0 of the stringent attacks.<br>
> =A0 =A0 Well to be ethical in this regard these are not the recent att=
acks but<br>
> =A0 =A0 are persisting from long time. The only<br>
> =A0 =A0 difference is the exploitation ratio has increased from bottom=
to top.<br>
> =A0 =A0 So that's the prime reason it has been<br>
> =A0 =A0 included in the web application security benchmarks. But the<b=
r>
> =A0 =A0 projection<br>
> =A0 =A0 of redirection attacks is active now.<br>
><br>
> =A0 =A0 This post is not about explaining the basics of redirection is=
sues. It<br>
> =A0 =A0 is more about the design vulnerabilities<br>
> =A0 =A0 in browsers that can lead to potential persistent redirection<=
br>
> =A0 =A0 vulnerabilities. Web application security can be<br>
> =A0 =A0 hampered due to browser problems.<br>
><br>
> =A0 =A0 Note: The base is to project the implications of browser ineff=
iciency<br>
> =A0 =A0 and the ease in conducting web application =A0attacks.<br>
><br>
> =A0 =A0 Post:<br>
> =A0 =A0 <a href=3D"http://zeroknock.blogspot.com/2010/01/link-injectio=
n-redirection-attacks.html" target=3D"_blank">http://zeroknock.blogspot.com=
/2010/01/link-injection-redirection-attacks.html</a><br>
><br>
> =A0 =A0 Video: <a href=3D"http://www.secniche.org/videos/google_chrome=
_link_inj.html" target=3D"_blank">http://www.secniche.org/videos/google_chr=
ome_link_inj.html</a><br>
><br>
> =A0 =A0 Browsers need to take care of these issues.<br>
><br>
> =A0 =A0 Regards<br>
> =A0 =A0 Aditya K Sood<br>
> =A0 =A0 <a href=3D"http://www.secniche.org"; target=3D"_blank">http://w=
ww.secniche.org</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>
--0016361648ed600a68047c7fd656--
Brought to you by http://www.webappsec.org
Search this site
|