lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALx_OUArgQ14M5rOrVJBdA77KjM41JAq9_9fS5KQJVJo310Z1Q@mail.gmail.com> Date: Wed, 7 Dec 2011 22:37:52 -0800 From: Michal Zalewski <lcamtuf@...edump.cx> To: Luis Santana <hacktalkblog@...il.com> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: Google open redirect > As for minimal risk I personally don't agree. I have leveraged Unvalidated > URL Redirections in the past to attack clients of sites all the time. It's > highly trivial to point to a site with a metasploit browser bug patiently > waiting and amass quite a large number of sessions in a short period of time > should your spam campaign be efficient and actually draw users to the > vulnerable site. The problem is that the current contents of the address bar are about the only security indicator you have in the browser. It's unfortunate, and many users don't truly grasp this; and even if they do, they don't understand the intricacies of the URL syntax - but still, that's what we have to live with. The security community should try to fix this huge problem - but the progress on this and many other fundamental challenges in browser security is often hindered by the dynamics of vendor-researcher interactions. For time being, if you make security decisions based on onmouseover tooltips, link text, or anything along these lines, and do not examine the address bar of the site you are ultimately interacting with, there is very little any particular web application can do to save you: you are just at a significant risk wherever you go. If you take away open redirectors, a myriad of other, comparable ways to fool you remain, and can't be fixed easily. For example: did you know that if you click on a link from coredump.cx to microsoft.com and it opens in a new window, then a second or two later, that coredump.cx in the background can change the URL of the microsoft.com window, and point it to evil.com? Heck, coredump.cx can even wait until you navigate further down the microsoft.com website - and detect that event programmatically. That behavior is enshrined within the current design of the same-origin policy, and browser vendors seem hesitant to touch it. I posted a brief rant about it about two years ago: http://lcamtuf.blogspot.com/2010/04/address-bar-and-sea-of-darkness.html I've been in the community for a while, and I hope it goes without saying that I'm not here to be a mouthpiece for my current employer; I just genuinely think it's a complicated problem, and we need to pick our battles carefully. Redirectors are not particularly desirable, but the big picture is less obvious than it seems. /mz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists