Gravatar now restricts default URLs

Bug #1057832 reported by François Marier on 2012-09-28
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

A URL like this:

will be redirected to Gravatar like this:

which used to end up here:

but now ends up here:

This breaks sites that used local paths instead of full URLs in their "default" parameter.

For, this means that we now effectively have two different behaviours:

1. when using an MD5 hash, you get the Gravatar behaviour because we redirect to Gravatar first
2. when using a SHA256 hash, you get the original behaviour because we never redirect to Gravatar

François Marier (fmarier) wrote :

I see two options to resolve this inconsistency:

1. we implement the same kind of server-side fetching and caching of arbitrary third-party images
2. we drop the SHA256 hashes and redirect everything through Gravatar

Option #2 would of course be undesirable since it leads to a feature loss (and the MD5 problem is only going to get worse as time passes), but option #1 has several problems in our distributed environment:

- an attacker could abuse this server-side fetching and DoS the server's bandwidth or disk space by causing it to download lots of large images (Gravatar is affected by this problem, but they have more money!)
- it makes third-party implementations a lot harder

François Marier (fmarier) wrote :

Another option would be to keep the SHA256 hashes but to remove arbitrary default URLs from them.

So you could choose to use a SHA256 with any of the built-in "special values" but not redirect to an arbitrary image. Arbitary redirections would only be available through Gravatar with an MD5 hash.

François Marier (fmarier) wrote :

I should also mention that the alleged reason why Gravatar made this change is that they themselves used to obscure spam / malware links in phishing emails.

Which means that we may not want to ignore this issue entirely and restore the old functionality.

François Marier (fmarier) wrote :

As Christian pointed out on IRC, this change really sucks for Intranets.

Christian Weiske (cweiske) wrote :

I see an variant of option #1: The libravatar server sends a HEAD request to gravatar, asking them to respond with a 404 if the image does not exist. In that case, libravatar redirects to the default URL. Otherwise it redirects to gravatar.

This way, we'd keep the possibility to use publically unreachable default images, for example in intranets.

François Marier (fmarier) wrote :

Here's a note about this change from the official Gravatar blog:

François Marier (fmarier) wrote :

Christian: doing a server-side curl of the Gravatar URL would change the way that the mirrors are architected. It would mean that they are no longer just serving static files and instead and actively fetching URLs on every request. This is going to be expensive and will likely double or triple their bandwidth usage, in addition to severely increasing the latency of these requests.

In addition, we should probably still address the security problems that Gravatar has been running into. I can't see a way to do that while preserving Intranet images unfortunately :(

François Marier (fmarier) wrote :

This thesis (section 3.3.2) explains one of the problems with arbitrary redirections: it allows an attacker to get other people to perform one-click exploits on their behalf, or distributed denial of service attacks.

Another problem is that avatar URLs can be used to obscure links in phishing emails. Either on their own or as part of a redirection chain.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers