The Danger Of Inlined Images
by Chris Josephes
Have you ever posted an image to a blog or a web forum, and then found out what you submitted was not the image that showed up in the posting? I found an interesting example of this on a popular news blogging site.
The comment had an image from a third party server. This third party server was configured to substitute images if the original file was being inlined from another web site. Most web servers, like Apache, can be configured to change the image based on the value of the Referer HTTP header.
Instead of the image you're expecting to see, you'll see a low resolution image with text saying something like, "Please visit my site", or "You're stealing my bandwidth". I'll refer to these images as nag images.
But in this case, the replaced image had no words or warnings. It simply showed a naked man and a parakeet, perched in a place where most people wouldn't perch a parakeet.
The posting was deleted by moderators, but not before people freaked out about seeing a "Not Safe For Work" image. One user discovered that this was a nag image. By viewing the image without a Referer header at all, the image was completely different.
Nag images may work with other websites, but they don't work with blogs. People commenting in blogs may not have the ability to retract or edit their comments once they are submitted. So once the image is posted, it's stuck there until an administrator can delete the posting.
To make matters worse, people posting to the blog may not even see the nag image in Preview mode. If the image is cached in the browser, it will appear to be just fine, becase the web server's Referer check was never made.
Now if you happen to be an author that writes blogging software, there is a way that you can prevent these nag images from showing up in your site.
If any site user makes a posting that inlines images from a third party server, the editing software should retrieve the image twice using the HTTP HEAD method. For the first retrieval, don't pass a Referer header. For the second retrieval, set a Referer header that would reference the full URL of the page that would eventually load the image.
For both requests, the HTTP server headers Content-Length and ETag should return identical values. If they don't, that means the web server is sending out different files. Make sure the comment poster is aware of this, and give them the opportunity to correct the problem.
Or you could just stop them from hotlinking to remote images. It's really not a good idea to begin with, because even if they don't do a content switch on you, you're still stealing bandwidth. Make the users/commenters link *to* the image, not display the actual image.
The problem with that theory is, you're automatically assuming all displayed images from third party servers are being displayed without authorization.