Full Disclosure mailing list archives
Re: Google open redirect
From: Tavis Ormandy <taviso () cmpxchg8b com>
Date: Thu, 8 Dec 2011 11:30:53 +0100
Nick FitzGerald <nick () virus-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 () e ch">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 () cmpxchg8b 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/
Current thread:
- Re: Google open redirect, (continued)
- Re: Google open redirect Charles Morris (Dec 08)
- Re: Google open redirect Pablo Ximenes (Dec 08)
- Re: Google open redirect Charles Morris (Dec 08)
- Re: Google open redirect Michal Zalewski (Dec 08)
- Re: Google open redirect Pablo Ximenes (Dec 08)
- Re: Google open redirect Valdis . Kletnieks (Dec 08)
- Re: Google open redirect Gage Bystrom (Dec 08)
- Re: Google open redirect Pablo Ximenes (Dec 08)
- Re: Google open redirect Valdis . Kletnieks (Dec 08)
- Re: Google open redirect secure poon (Dec 08)