实际上，它们可能是恶意的。29C3 的 CTF 的挑战之一实际上是上传图像并使用它执行 SQLi。

它是如何工作的？那么图像有元数据，在你上传图像后，元数据被提取并放入数据库。所以获得标志的诀窍是在元数据中包含 SQL。（输入未正确清理）。

是和不是。

图像只是数据，因此，它们与表单字段、GET 参数或任何其他类型的用户提供的数据没有什么不同。它们实际上并没有什么特别之处，只是您将收到的大多数其他数据都是文本的，并且它们通常不包含任何“可能类似于 SQL”的内容。后者是一个错误的假设，因为大多数图像文件格式都适合元数据，这使得在其中嵌入 SQL 变得非常容易，即使它们不这样做，也可以制作一个包含 SQL 作为二进制数据流的一部分的图像文件不应该太难。

长话短说：如果您的查询参数化是有序的（无论如何您都应该这样做），那么您就和任何其他用户提供的数据一样担心：只要您将图像 blob 作为参数传递，并且数据库 API 的参数化调用不容易受到攻击，你很好。但是，如果您决定将已从上传文件中提取的内容连接到查询中，您将遇到与表单字段中的 SQLi 漏洞完全相同的问题。

文件上传需要注意的另一件事是远程代码执行。如果您不小心，攻击者可以上传一个伪装成图像的 PHP 文件，并欺骗您的脚本将其保存在可以通过 apache 访问和执行的位置（或者更糟糕的是，保存在被系统本地进程拾取，在最坏的情况下，以root身份运行的进程）。这里的防御是验证文件的 MIME 类型并将其列入白名单，确保其扩展名与 MIME 类型匹配，清理（或完全替换）文件名，并将其存储在 docroot 之外的某个位置。

只要您验证图像实际上是图像，图像上传就不会直接受到 SQL 注入的攻击。我的意思是不仅仅依赖于文件名。有人可能会上传一个根本不是图像并且包含 SQL 注入脚本的“图像”。如果图片中包含 SQL 命令，那么图片上传会间接让您面临 SQL 注入的风险。

还有很多与图片上传相关的其他潜在问题，包括阻止用户上传受感染的图片（几种图片类型可能被恶意软件感染），如果网站制作不当，他们可能会使用收集到的图片从上传图像到弄清楚如何进行目录遍历攻击。但这些与 SQL 注入有很大不同。

参见：（相关攻击）

• https://www.owasp.org/index.php/Unrestricted_File_Upload
• https://www.owasp.org/index.php/Path_Traversal
• https://www.owasp.org/index.php/Path_Manipulation
• https://www.owasp.org/index.php/Windows_::DATA_alternate_data_stream
• http://php.webtutor.pl/en/2011/05/13/php-code-injection-a-simple-virus-written-in-php-and-carried-in-a-jpeg-image/

最后，下面提到了确保上传的项目实际上是图像的步骤。

• https://stackoverflow.com/questions/4166762/php-image-upload-security-check-list

镜像文件本身不会做SQL注入，但是镜像文件不是单独来的；它包括一个文件名。SQL 注入是关于服务器代码在对 SQL 数据库的请求中不小心包含字符串，其中包含的字符串来自潜在的敌对远程用户。文件名是远程用户选择的字符串。所以...