设置 mimetype

有风险，判断文件头是不完全的。你可以参看

http://zone.wooyun.org/content/5429

你需要在服务端禁止执行这些代码。简单的说，就是不管他的扩展名是什么，反正这个目录是静态的，不要丢改cgi之类的东西。

如果你是虚拟主机环境，你可能面临对主机环境无法深度配置的问题。
如果你想求个放心，我建议把这些用户上传的静态文件，托管到又拍云、七牛云等外部的CDN服务器上去。
放到外边去就不可能（也不用关心）有php会被意外执行的安全问题了。对于虚拟主机跑得起来的小站，花费也不多甚至几近免费。

10-23补充：想到一个正面突破的好办法。

用户上传之后，存储成任意安全的扩展名（例：raw、bin等）。在需要调用的时候，通过一个php脚本作为中间层传递文件内容（读取请求的文件名，找到文件，把图片文件类型对应的MIME写入HTTP头，图片文件实际的内容写入HTTP正文）。

例如：http://example.com/attach.php?id=13776。
也可以用一种更加优雅的语法：http://example.com/attach.php/13776.jpg
或http://example.com/attach.php/13776；
甚至动用rewrite实现类似http://example.com/attach/13776的URL。

这样会收到若干好处：

1. 绝对安全。所有的恶意代码都绝对不经执行，通过HTTP原样返回浏览器，给攻击者个自讨没趣。
2. URL显而易见，符合REST原则，外人无法从URL猜测程序的目录结构。
3. 经过PHP，就方便实现鉴权、防盗链等若干实用功能。
4. 保持网址恒定性，无论是程序目录结构修改，还是静态文件将来托管到CDN上，网址都保持不变。

据我所知 原来有个漏洞，如果目录名是 a.php 然后目录里的 a.jpg 会被当作 PHP 执行。

直接上图片处理，gd或者imagick等，重新存一下

用图形库验证一下。不是图片不让上传。

当 nginx 搭配 php-cgi 时候，在路径解析问题上可能要防下。当年争议比较大的就是 cgi.fix_pathinfo 的问题。另外当nginx 处于反代模式时。mimetype 设置的对，应该没什么问题。

如果是Nginx的话可以考虑区分jpg和php的文件夹，即使上传了jpg但是路径不对也不会被执行0.0

chmod 0444 a.jpg

禁止文件执行

gd库获取一下图片的长宽大小，为0阻止。