Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.

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

BUT stackexchange saved the image on its server, here is the URL of that image:

http://www.ipnow.org/images/iprand.jpg

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

share|improve this question

3 Answers

up vote 4 down vote accepted

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.

share|improve this answer
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 at 21:18
1  
@Akam That is one solution to an LFI attack, PHP's open_base_dir is another solution. – Rook Mar 4 at 21:19

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.

share|improve this answer
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 at 21:06

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 !

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.