Closed maddrid closed 8 years ago
Hi, first I'll put links that you sent me here:
http://websec.io/2012/09/05/A-Silent-Threat-PHP-in-EXIF.html https://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html http://phocean.net/2013/09/29/file-upload-vulnerabilities-appending-php-code-to-an-image.html
Now, I am no security expert for PHP, but this part would be a partial responsibility of iMagick/GD as well as Osclass. I do not know in detail how iMagick handles images (but I assume they are aware of potential threats), but if you look into class how it is done in case of GD, images are not included, but read via file_get_contents()
which is recommended in one of the above articles.
Second, if you remove exif right upfront, you will lose auto-orientation feature, which is important. Osclass checks only single exif field (orientation) which is just an integer really. I do not know if this is a risk or not. Update:
saved images, of course, do not keep exif data.
Now, there is a recommendation to store original user images in inaccessible area. One other method could be to assign them a random string name and store that reference inside database (obscurity ?). Ok, that might not be good idea. However, you may choose not to keep originals - problem solved. On the other hand, if you modify something and wish to regenerate them, you will have a problem without original files. In any case, on production sites originals are rarely kept and media modified later.
Some thought from Conejo or Garcia on this might put more light.
I thinks that it's not an issue.
Osclass core don't include images using:
include, require, include_once
This is the only way the php inside an image exif will be executed.
Some housekeeping is needed when we save original image . Original image keeps original exif headers (Hidden php can be Inside EXIF Headers ). Create new image with original dimensions or exif headers must be cleaned . Default option save original image to no ?