How to prevent XSS injection while allowing users to post external images

A user recently reported to me that they could exploit the BBCode tag [img] that was available to them through the forums.

[img=http://url.to.external.file.ext][img]

Of course, it would show up as a broken image, however the browser would retrieve the file over there. I tested it myself and sure enough it was legit.

I'm not sure how to prevent开发者_StackOverflow中文版 this type of XSS injection other than downloading the image and checking if it is a legitimate image through PHP. This easily could be abused with a insanely huge file.

Are there any other solutions to this?

---

You could request the headers and check if the file is actually an image.

Edit:

Sorry that I couldn't answer in more depth; I was enjoying dinner.

There are two ways I see it:

1. You check to see if the supplied address is actually a image when the post is submitted or viewed, you could accomplish this by checking the headers (making sure it's actually an image) or by using file extension. This isn't fool-proof and has some obvious issues (changing the image on the fly, etc.).
2. Secure your site that even if there is a compromise with the [img] tag there is no real problem, for example: the malicious code can't use stolen cookies.
3. Use a script that requests an external image and modifies the headers.

A basic way to check the remote files content type:

$Headers = get_headers('http://url.to.external.file.ext');
if($Headers[8] == 'text/html') {
    echo 'Wrong content type.';
    exit;
}

---

There's only two solutions to this problem. Either download the image and serve from your webserver, or only allow a white-list of url patterns for the images.

Some gotchas if you decide to download the images -

1. Make sure you have a validation for the maximum file size. There are ways to stop the download if the file exceeds a certain size, but these are language specific.
2. Check that the file is actually an image.
3. If you store it on the hard-disk, be sure to rename it. You shouldn't allow the user to control the file name on the system.
4. When you serve the images, use a throw-away domain, or use naked ip address to serve the images. If the browser is ever tricked in thinking the image is executable code, the same-origin policy will prevent further damage.