Re: Google open redirect

[Marsh Ray <marsh () extendedsubset com>]

On 12/10/2011 06:20 AM, Tavis Ormandy wrote:
> I'm not sure I understand whether you're saying that vendors need to make
> users expectations match reality,

A. The vendor, through their UI, needs to set users' expectations properly.

B. The actual security of the user needs to live up to what is 
communicated through the UI.

> or if users need to learn how to make
> security decisions properly.

C. Well that too.

I think C is not going to happen without A & B.

Vendors should not design security features to the lowest common 
denominator. They should hold users to a higher standard than that 
implied by "typical user" studies, lest low expectations continue to 
form a self-fulfilling prophecy.

> 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 know I don't know how to do it.

But at the same time, there are some URLs that I'm more scared to click 
than others.

> 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.

Perhaps, but often it seems that UI designers and security people alike 
are absolutely convinced that users can *never* be effectively educated.

> 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.

It becomes a vulnerability when a system relies on the absence of that 
capability for its security.

Do any?

Hopefully not, but often the user is a critical part of the system too.

After the whole goatse.cx gag started to get old, sites which allowed 
users to post links (like Slashdot) began always putting the domain in 
the text after the HTML link text. Now this is probably not a critical 
security feature, but it can be defeated with an open redirect 
accessible via [google.com].

I used to think phishing was a silly trick and didn't qualify as a 
"real" attack, but it sure seems highly effective in certain real-world 
contexts. Today there's a recognized attack category called "social 
engineering", I used to just think of all that as "con games".

> 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.

I am in complete agreement with you.

Let's say you are a bank that has just invested in a successful 
anti-phishing user education campaign. All the users have been trained 
to look beneath the HTML in emails, not to accept invalid SSL 
certificates, and only follow "legitimate" links that look like:

      https://*.examplebank.com/

At that point an open redirect is found under your site, such that
https://onlinebanking.examplebank.com/confirm.aspx?customerid=1234&return=http%3a%2f%2fpwn%2ely 
drives the browser to the attacker's phishing site.

Does this represent a vulnerability?

- Marsh

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/