Skip to main content
Information Security

Return to Answer

elaborated on malware scanning, added permission settings
Source Link
buherator
buherator
  • 1.8k
  • 1
  • 9
  • 15

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • As FakeRainBrigand pointed out, you should set the file permissions to non-executable to reduce the risk of OS-level execution (also some PHP configurations require scripts to be executable).

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that, as detecting this kind of malicious code would require a whole other AntiVirus-like system that would eventually face the Halting problem.

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that.

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • As FakeRainBrigand pointed out, you should set the file permissions to non-executable to reduce the risk of OS-level execution (also some PHP configurations require scripts to be executable).

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that, as detecting this kind of malicious code would require a whole other AntiVirus-like system that would eventually face the Halting problem.

added 1 characters in body
Source Link
buherator
buherator
  • 1.8k
  • 1
  • 9
  • 15

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions orand filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that.

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions or filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that.

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that.

Source Link
buherator
buherator
  • 1.8k
  • 1
  • 9
  • 15

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions or filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that.