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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Dec 2011 13:20:31 +0100
From: Tavis Ormandy <taviso@...xchg8b.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google open redirect

Marsh Ray <marsh@...endedsubset.com> wrote:

> On 12/08/2011 12:37 AM, Michal Zalewski wrote:
> >
> > 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.
> 
> I think reasoning based on this is subtly fallacious and it often
> contributes to disagreements between researchers and large vendors. This
> is how we got into the state of the web today: bad faith on the part of
> browser vendors.
> 
[...]
> 
> Avoiding security improvements because the are perceived as being of
> little benefit to type typical user is wrong. Doing so gains nothing for
> the typical users, it decreases the security available to competent and
> contientious users, and worst of all it actively removes any incentives
> for the "typical user" to begin to take responsibility for their own
> security.
> 

I'm not sure I understand whether you're saying that vendors need to make
users expectations match reality, or if users need to learn how to make
security decisions properly.

I think it's a believable claim that a large number of users have
(incorrectly) decided that they can make security decisions using the status
text or the appearance of a URL anywhere other than the address bar. I would
be in favour of making that expectation match reality, but it's simply
technically infeasible due to a number of fundamental computer science
problems.

The reality is that pleading with everyone in the world to stop using
redirection wouldn't solve the problem, and (in my opinion) is much harder
than trying to find these users and educating them about how to achieve the
desired effect correctly.

Trying to call "open redirection" a vulnerability strikes me as hilarious.

"An attacker that can make a user visit an arbitrary URL can make a user
visit an arbitrary URL"

Well, there's no vulnerability there, so let's revise it.

"An attacker that can make a user visit a URL from a domain they trust can
make a user visit a URL from a domain they don't trust".

Okay, but there's no way to determine if a URL is trusted or not unless you
read it from the address bar. HTTP redirection doesnt do this, as the
address bar is correctly updated, so let's revise again.

"An attacker that can make a user who doesn't know how to determine if a URL
is trusted or not visit an arbitrary URL, can convince a user to trust an
arbitrary URL."

Well obviously :-)

But now if we successfully convince every developer on the planet to stop
using HTTP redirection, that doesn't change that the user doesnt know how to
determine if the URL is trusted or not, so we just use one of dozens of
other simple tricks.

Surely the correct solution is to educate those users who are doing it
incorrectly.

Tavis.


-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ