About Hotlinking and CSRF

Today GNUCitizen posted a blog : Persistent CSRF and The Hotlink Hell.

From GNUCitizen's post
It is not Google’s fault. I am not sure what exactly needs to be done in order to fight against this type of attacks.

First of all I don’t know why pdb thinks this is not Google’s fault and I don't know why he thinks there should be a different protection against it. This is definitely Google’s fault and this is a very obvious CSRF issue and protection against it is obviously same.

Beside of the all rewrite issue, we all know hotlinking is bad because,

- May leak session identifiers, unique identifiers etc.
- May allow hotlinked server to track your traffic
- May allow hotlinked serverd to see your querystrings, search strings etc.
- Can lead WMF or similar exploits
- and of course potential goatse attacks!

None of these are critical issues but important. Be sure you protected against CSRF. If you got a serious CSRF issue in your application it doesn't matter you hotlinking or not. It can be exploited but you can think hotlinking + CSRF like permanent XSS vs reflected XSS. Impact is same but attack can be easier to launch or it can affect more people easier.

When it comes the dilemma of showing external images, it's a very similar issue with accepting HTML but not allow to execute dynamic content. Which is possible but implementation can be damn hard.

There are other issues like performance, scability, bandwith etc. when you think about a more secure implementation (local caching, checking image file formats etc.) in a real world application.