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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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