我使用了一个特殊的图片上传技巧，绕过PHP GD库对图片的转换处理，最终成功实现了远程代码执行。
事情是这样的。当时我正在测试该网站上是否存在sql注入漏洞，不经意间我在网站个人页面发现了一个用于上传头像的文件上传表单。开始时我并没指望在上传功能处发现漏洞，但我决定试试。
我上传了一个图片文件，通过截断http数据包，修改jpg图片的文件名后缀为php，然后继续上传。我惊讶的居然上传成功了，我几乎不敢相信这么简单的漏洞居然存在。于是我复制了图片url并且在浏览器上打开。进入我眼帘的是图片的二进制代码，这意味着图片以php解析了，并根据响应包里的 content-type以text/html格式返回。
我现在要做的是在jpg文件中注入php代码以进行远程代码执行，于是我尝试将代码写入图片的EXIF头里，但是悲剧的是再次上传发现php代码没有被执行。
在本机进行了测试，结果仍然无效——代码没有被执行
在上传到服务器后，EXIF里的代码都被删除了，应用通过imagecreatefromjpeg()函数调用了PHP GD库(GD库，是php处理图形的扩展库)，对图片进行了转换。那么如果不将代码注入EXIF头而是注入到图片里呢?
本机测试通过，但当我上传“1.jpg”到服务器上，返回以下结果：
报错上写着“文件必须是合法的图片(.gif, .jpg, .jpeg, 或.png)”，我惊叹于应用是怎么判断图片不合法的。我又测试了一些其他jpg文件，结果发现修改任何一个图片字符都会引起php-gd库的错误判断，进而造成上传失败。
接下来我又使用gif图片进行了同样的操作，结果是：图片上传成功了，但是图片中的php代码完全被删除了。
虽然这看起来不可思议，但是我不能放弃，因为现在距离成功利用远程代码执行(RCE)只有一步之遥，我必须绕过imagecreatefromgif()函数。我对图片的处理和php GD库的运行知之甚少，可是这不影响我使用一些传统渗透测试方法。
我想到一个方法：对比两张经过php-gd库转换过的gif图片，如果其中存在相同之处，这就证明这部分图片数据不会经过转换。然后我可以注入代码到这部分图片文件中，最终实现远程代码执行。连我自己都佩服我的机智!
如图，我用十六进制编辑器打开图片文件，找到了php转换前后仍然保持相同的十六进制串“3b45d00ceade0c1a3f0e18aff1”并修改它为。
保存图片，上传到服务器：
我的PHP代码被执行了，我最终成功实现了远程代码执行。