Hacker News new | ask | show | jobs
Google Domain Name Exploit (google.com)
1 points by salehhamadeh 4458 days ago
2 comments

From Google (http://www.google.com/intl/US-en/about/company/rewardprogram...):

URL redirection: Some members of the security community argue that open redirectors are a security issue. The common argument in favor of this view is that some users, when presented with a carefully crafted link, may be duped into thinking that they will be taken to a trusted page - but will be not be attentive enough to examine the contents of the address bar after the redirection takes place.

On the other hand, we recognize that the address bar is the only reliable security indicator in modern browsers; and consequently, we think that any user who could be misled by a URL redirector can also be tricked in other ways, without relying on any particular trusted website to act as a relying party.

The reward panel will likely deem URL redirection reports as non-qualifying: while we prefer to keep their numbers in check, we hold that the usability and security benefits of a small number of well-implemented and carefully monitored URL redirectors tend to outweigh the true risks

This seems important and something I should look into implementing, but you completely lost me here:

> "Keep a hash map of URLs. In other words, instead of having the URL in the query string, have a key that refers to that URL there. In this way, only the URLs for the keys that YOU define are redirectable."

Huh? I wish you would expand on this a little bit.

This is exactly what happened with the first era of URL shorteners, and has the detrimental effect of scattering dead links around the web when your service closes. (termed link rot)

ArchiveTeam has a project scraping URL shorterners to attempt to archive exactly these things. Their tagline is "url shortening was a fucking awful idea".

http://archiveteam.org/index.php?title=URLTeam

My takeaway from this is that having a whitelist is fine, but keep the original URL visible so that if your service isn't available the original content is still visible (although potentially requiring manual user effort) is a good thing.

Make a mapping of some ID to a URL in a database, make the final URL that redirects have the ID in it, not the target URL.

That being said, this whole thing is pretty silly with the given examples. If banks were doing this it'd be another issue.

test.org/redirect?url=http://test2.com

vs

{'test2':'http://test2.com'} on server + test.org/redirect?url=test2