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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 8 Dec 2011 11:30:53 +0100
From: Tavis Ormandy <taviso@...xchg8b.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google open redirect

Nick FitzGerald <nick@...us-l.demon.co.uk> wrote:
> _Open_ URL redirectors are trivially prevented by any vaguely sentient web
> developer as URL redirectors have NO legitimate use from outside one's own
> site so should ALWAYS be implemented with Referer checking, ensuring they
> are not _open_ redirectors...
> 

Although it is possible to trivially prevent redirecting, your technique of
referer checking is not a good way to achieve that. The real question is why
do you have a bee in your bonnet about redirection?

The attack proposed is to find a user who doesn't understand that the
address bar is the only security indicator supported by browser vendors, and
then to convince them to ignore the address bar while they're being
attacked.

I don't dispute that you could probably produce a user that would be
vulnerable to this attack, perhaps someone who calculates trust based on the
statusbar text when mouseovering a link. Many users incorrectly believe this
is a security mechanism, however the existance of open redirectors isn't
what makes this exploitable.

These users would still be vulnerable to tricks like this:

<a href="http://good.com" onmousedown="this.href='http://bad.com'">link</a>

Perhaps you would argue that there is a subclass of users who do not
understand how to determine the current domain, but also disable javascript,
or who read their email in mutt. These users would be vulnerable to
unsophisticated attacks like these:

<a href="http://www.good.com.e.ch">good</a>  (Misleading subdomains)

<a href="http://bad.com">http://good.com</a> (Misleading anchor text)

<a href="http://www.good.com@...h">link</a>  (Unusual URL syntax)

And so on.

To save time, I've also heard the following arguments:

* There have been a number of vulnerabilities were exploitable because of
open redirectors, therefore they are indirectly bad.

There have been a number of vulnerabilities in just about every possible
browser subsystem. Do you propose we ban pdf files because of CVE-2007-0045?
Or ban tables because of MS10-090? A better approach seems to be to fix the
vulnerability, rather than plead with every web service provider in the
world to stop implementing useful parts of the HTTP spec.

* My company sells a URL blacklist product, and open redirectors break it.

Enumerating known bad will always fail. If the existence of tinyurl breaks
your product, then your product was flawed.
 
* Spammers or phishers really use open redirectors!

Rule #3. Using an open redirector actually introduces a new single point of
failure outside of their control into their operation, and so it could be
argued this is a good thing ;-)

If you care about spam, you now have an additional point to potentially
neuter their operation.

My (perhaps cynical) opinion is that because open redirection is such a
useful and natural thing to want to implement, and are therefore so common
and easy to find, this vulnerability class was invented to pad lacklustre
reports from consultants.

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