I am filtering all images that attached to any content of my blog:

  1. Check for file extension.
  2. Check content type using $finfo = finfo_open(FILEINFO_MIME_TYPE);
  3. I also save the image temporary on my server and check the size using getimagesize() then I delete it if the function not returned false.

But after these checks, I will not re-check the image.

What happened to me

On one user profile I can see my IP address on the image each time I visit the user profile. This is an example I attached to this post:

enter image description here

Now, I can conclude that allowing user to attach any image will be dangerous because of this cloaking file attack that can generate dynamic image on each request.

Is there any mechanism to prevent this?

or should I remove all attached images from user profile and saving each image on my server

3 Answers 3


If its just a simple profile picture, you can avoid most security threats by using a trusted 3rd party like Gravatar(which is what security.se uses). Using a linked image as a "Web Bug" are unavoidable with remote images but apparently a lot of people don't care that Gravatar can track them. Storing an attacker-controlled file locally creates other security threats.

More generally, you do not want to store user-controlled files on your server. A good example of exploiting this type of vulnerability is using a PHP local file include (LFI) vulnerability to obtain remote code execution. Even storing an attacker controlled file temporarily is a security threat that can be exploited with an LFI attack.

Verifying that the link is in fact an image using getimagesize() helps prevent CSRF. However, even a valid image file can contain PHP tags in the EXIF metadata, and that could be used in a LFI attack. LFI attacks like this can be prevented using PHP's open_base_dir configuration option to prevent PHP from including files in the image or temporary directories.

  • Then, in this case, the best option is to host all images on server that PHP or any server-side programs not enabled?
    – Akam
    Mar 4, 2013 at 21:18
  • 1
    @Akam That is one solution to an LFI attack, PHP's open_base_dir is another solution.
    – rook
    Mar 4, 2013 at 21:19

When an external image is "attached" to the comment, then one of these two things occurs, depending on the way your server handles such things:

  • A reference to the URL pointing to the image is kept, and reproduced in the HTML file which is returned to any client browser visiting your site.
  • The image is downloaded by your server, and the clients will receive the copy which you keep on your server.

In the first case, every client who visits your page will automatically download the image, and the server at the other end (not yours, the one containing the image) can serve any image as it sees fit, possibly depending on who is currently asking (that's how the "show my IP" pictures work). Even if you yourself browse the page with your browser, you cannot be sure that every other visitor will see the same thing. Also, the sysadmin at the server which contains the image will be able to gather the IP address for every visitor of your site.

Last but not least, a maliciously crafted "image" link can point at things other than images, and unwillingly enroll all the visitors of your site in a distributed denial-of-service.

It thus seems safer to get a copy of the picture on the server, and serve it to visitors from your server only. This should be coupled with a validation/conversion step which checks that the image can be decoded, and forces it to have a "sane" size. Beware of scriptable image formats like SVG !

  • 1
    Can you explain how does the DDOS work? Since the bits are interpreted as image, how could that happen?
    – Pacerier
    Oct 12, 2013 at 13:52
  • Interpretation is local; it does not matter here. I.e. the link points to a page on a target site; everybody who browses the page where the link is will download the page from the target site as well. That the returned bytes do not make sense as a picture does not matter, since the browser will see it only after it has done the download. The attacker wants a lot of downloads to happen (that's the DDoS) but does not care whether it "looks pretty" aterwards in the Web browsers which unwillingly participated to the attack.
    – Tom Leek
    Oct 12, 2013 at 14:30
  • Why will the malicious image hoster DDOS himself? Or rather, how can the malicious image hoster DDOS anyone but himself?
    – Pacerier
    Oct 12, 2013 at 14:56
  • The attacker arranges for a page, on server A (as "attacker", but it could be an honest blog server which allows for links in user comments), which many people look at, to contain a link to some resource on server V (as "victim"). Every user who visits the page on A will automatically download the other page on V, as if it was an image. If the source page (on A) is small, but the target page (on V) implies something expensive for V, then all the users who browse the page on A effectively DDoS the server V, with a much smaller cost for server A.
    – Tom Leek
    Oct 12, 2013 at 15:08

Not only can they tell your IP, but they could also guess at what kind of browser you're running and what website sent you there (referer header).

Yes, the only way to control image privacy is to keep those images hosted on a server whose Privacy Policy you control, and in your case that would include copying the images to your server.

  • consider if an attacker changed the image to javascript file, or .exe file, because according to my search this is possible using .htaccess file with PHP?
    – Akam
    Mar 4, 2013 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .