php shell 可以注入到图像中吗？这将如何运作？
我记得看到过对图像上传功能的利用，其中包括将恶意 php 代码隐藏在 tiff 图像中。
我正在制作自己的图像上传脚本，我想我必须保护自己免受这种可能性的影响。不过，我不知道它是如何运作的。有谁知道隐藏在图像中的 php shell 如何自行执行？是否需要以某种方式加载？
谢谢。
I remember seeing an exploit for an image uploading function, which consisted of hiding malicious php code inside a tiff image.
I'm making my own image uploading script, and I assume I'll have to protect myself from this possibility. Except, that I have no idea how it would work. Does anyone know how a php shell hidden inside an image would execute itself? Would it need to be loaded in a certain way?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
重新编码图像不会阻止某人上传 shell。防止这种情况的唯一可靠方法是重新编码并扫描图像是否存在 php 标签。
有关 PHP PNG shell 的示例，它将重新编码后仍然存在
Re encoding the image will not stop someone from uploading a shell. The only sure way to prevent it is to re-encode and scan the image for the presence of php tags.
For an example of a PHP PNG shell that will survive re-encoding
有一些方法可以保护自己免受此类欺骗。 查看它们
请在此处 阅读这篇文章，其中解释了攻击以及解决方法。
其中强调的要点是使用 php 的 basename 函数来推迟这种情况攻击。
There are some methods to protect yourself from such tricks. Check them out here
Also read this article which explains the attack and ways to tackle it.
The main point stressed in these is the use of basename function of php to defer such attacks.
您可以将 Web shell 编码为 png 图像，如果正确的话，它也能够在重新编码后幸存下来。
看看这个
You can encode web shells into a png image, if you make it right, it will be able to survive the re-encoding as well.
have a look at this
我知道有一种方法（或者曾经是一种方法）将 php 文件另存为
.gif并让它运行代码。在我在下载页面上看到的一个漏洞中，mime 类型被设置为 GIF，并且图像加载了一些效果如下的内容：require('myimage.gif');Whenmyimage.gif实际上是一个重命名为.gif的 PHP 文件，包含该文件会执行 php 负载，否则该文件只是一个普通的 gif。我看到了上传脚本的漏洞，黑客还对myimage.gif进行了十六进制编辑，以便字节47 49 46 38 39位于文件的其余部分之前。这些字节是 GIF 标头，会欺骗 PHP 认为该文件是 GIF，从而允许绕过“高级”文件类型检查上传 PHP 文件。通过构建更好的文件检查以确保整个文件合法，可以轻松解决此问题。我能想到的最简单的方法是尝试使用 GD 加载图像并查看是否有错误。我不认为 GD 会执行 PHP 有效负载，但我不确定，你必须进行测试。我假设对 tiff 或任何文件类型进行了或可以进行几乎相同的利用。为了确保您的脚本不被利用，我将采取以下步骤。
1) 设置一些可以执行的文件类型
Array('.png', '.jpg', '.txt', 'etc')如果它不在数组中则不允许这样做。即使您不允许.php，仍然有.php3、.php5等可以在某些服务器上运行。2) Gaard 通过将上传的文件保存为文件名（不包括文件类型）的 md5（或兰特名称）来攻击
myimage.php.gif，因此myimage.php .gif将变为ef0ca703846cdb7a0131ac2889304a27.gif3) 检查文件的完整性，确保文件头和其余部分都是合法的。
4) 不要使用
require('myimage.gif');而是打印其内容I know there's a way (or was) a way to save a php file as a
.gifand have it run the code. In an exploit I saw on the download page the mime type was set as a GIF and the the image was loaded with something to the effect of:require('myimage.gif');Whenmyimage.gifwas actually a PHP file renamed as.gif, including the file would execute the php payload, otherwise the file was just a normal gif. I saw this exploit for an upload script, the hacker also hex editedmyimage.gifso that the bytes47 49 46 38 39preceded the rest of the file. Those bytes are a GIF header and would trick PHP into thinking the file was a GIF allowing the PHP file to be uploaded bypassing the 'advance' file type checking. This could easily be fixed by building better file checking that made sure the entire file was legit. The easiest way I can think of would be to try to load the image with GD and see if it has an error. I don't think GD would execute the PHP payload but I'm not sure, you would have to test. I assume nearly the same exploit was done or could be done for a tiff or any file type.In order to make sure your script is not exploited I would take these steps.
1) Set a few file types that you can do
Array('.png', '.jpg', '.txt', 'etc')if its not in the array DO NOT allow it. Even if you disallow.php, there's still.php3, .php5etc that work on some servers.2) Gaard against
myimage.php.gifby saving the uploaded file to a md5 (or a rand name) of the file name (with the exclusion of the file type) somyimage.php.gifwould becomeef0ca703846cdb7a0131ac2889304a27.gif3) Check integrity of file, make sure both the header and the rest of the file is legit.
4) Do not use
require('myimage.gif');instead print it's content是的，它需要加载，可能是通过包含路径中用户提供的变量来加载，例如：
他们还可以允许用户使用 .php 扩展名设置整个文件名，因此他们需要做的就是加载它在浏览器中。
检查
getimagesize()是否返回 false、使用随机文件名并强制执行文件扩展名。如果可能的话，不要将上传的图像存储在可通过网络访问的位置，因为它也可能包含 JS，因此是 XSS 向量。重新编码图像还可以让您在末尾删除讨厌的元数据和垃圾，这是多种格式（例如 JPEG）所允许的
Yes it would need to be loaded, probably by a user-supplied variable in an include path, e.g.:
They could also have allowed the user to set the whole filename with a .php extension so all they'd need to do is load it in a browser.
Check that
getimagesize()doesn't return false, use a random filename, and enforce the file extension. If at all possible don't store the uploaded image in a web-accessible location as it could also contain JS and therefore be an XSS vector.Re-encoding the image can also let you strip nasty metadata and junk at the end which is permitted by several formats (e.g. JPEG)
如果您只使用 GD 函数来操作图像，那么应该没问题。
为了安全起见，您可以将所有传入图像转换为您可能认为“安全”的特定格式（我喜欢 PNG 或 JPG，具体取决于输出意图是在浏览器中显示还是某种高质量） -打印）。另外，切勿在您自己的文件系统上使用用户提供的 imoage 名称。这样它就无法在文件名中放入奇怪的数据。
为了更安全，您可以使用命令行 imagemagik 转换实用程序。这既更快又更安全。
If you only use the GD functions for manipulating the images you should be ok.
To be on the safe side, you may convert all incoming images to a specific format that you may consider "safe" ( i like PNG, or JPG, depending if the output intent is display-in-browser or some kind of hi-quality-print). Also, never use the imoage name supplied by the user on your own filesystem. This way it wont be able to put weird data in the filename.
To be even safer, you may use the command-line imagemagik conversion utility. This is both faster, and safer.
我不知道这个特定的漏洞，但通常这样的漏洞利用加载图像的软件中的错误。如果 PHP（或更准确地说，加载 TIFF 图像的库）将分配不正确的内存量来保存图像，则它可能会尝试在比保留的内存空间少的内存空间中加载图像。这称为缓冲区溢出。
这也意味着图像的一部分被加载到一块未为图像分配的内存中。这部分可能会被执行，因为它实际上可能是为代码保留的。
当图像库中存在错误时，可能会出现此类问题。我认为 IE 5 中的 GIF 存在这样的错误。分配的内存量不是由实际文件大小决定的，而是由文件头中的文件大小信息决定的。这使得人们可以制作损坏的 gif 文件，以一段编写在进程代码段中并且可以执行的代码结束。
I don't know about this particular exploit, but usually exploits like this make use of bugs in the software that loads the image. If PHP, or more exactly, the library that loads the TIFF image, will allocate an incorrect amount of memory to hold the image, it might try to load the image in less memory space than is reserved. This is called a buffer overrun.
That also means that a part of the image is loaded in a piece of memory that is not allocated for the image. This part might get executed because it could have actually been reserved for code.
These kinds of problems can arise when there is a bug in the image library. I think a bug like this existed for GIFs in IE 5. The amount of memory that was allocated wasn't determined by the actual file size, but by the file size information in the header of the file. This allowed people to make corrupt gif files, ending with a piece of code that was written in the code segment of the process and could be executed.
我突然想到了一个绝妙的解决方案。
如果您将图像存储在单独的服务器/域/CDN/任何无法直接访问您的代码的地方，那么您的任务就完成了！
A brilliant solution just came to my mind.
If you store your images on the separate server/domain/CDN/whatever has no direct access to your code, you have your mission accomplished!
是的，可以。使用以下代码创建一个 tif 文件 (php-code.tif)
然后在另一个脚本中 make
include 'php-code.tif';亲自看看会发生什么...
是的，包括这将意味着攻击者可以访问您的服务器，或者您自己上传文件作为 cms 的主题或插件...哎呀！
现在是防止此类攻击的第二部分，我还找不到可靠的解决方案，该解决方案适用于大多数 CMS，并且不涉及拒绝目录列表。仍在寻找...
Yes it can. Make a tif file (php-code.tif) with the following code
Then in another script make
include 'php-code.tif';See for yourself what happends...
Yes include this would mean the attacker has access to your server OR you uploaded the file yourself as a theme or plugin for a cms... oups!
Now the 2nd part for protecting from such attacks, well I could not find yet a reliable solution, which would work with most CMSs and not involve denying directory listings. Still looking...
除非 PHP 的图像处理存在严重错误，否则我不知道如何通过简单地使用或显示图像来解释图像中的 PHP 代码。
然而有一些方法可以使用图像对使用互联网的用户进行跨站点脚本攻击Explorer
您还需要注意，用户无法上传将用作 PHP 输入的图像。例如。由于某种原因被 include()d 或通过使用 .php 扩展名上传。
Apache Multiviews 甚至可能导致在某些情况下执行名为 image.php.jpg 的图像（尽管我不确定这一点）。
Unless there's a serious bug in PHP's image handling I don't see how PHP code in an image could ever be interpreted by simply working with it or displaying it.
However there are ways to use images to do Cross-Site-Scripting attacks on users using Internet Explorer
You also need to be careful that users can't upload images that would be used as PHP input. Eg. be being include()d for some reason or by being uploaded with a .php extension.
Apache Multiviews might even lead to images named like image.php.jpg be executed under some circumstances (though I'm not sure about this one).