Я помню, как я видел эксплойт для функции загрузки изображений, которая заключалась в сокрытии вредоносного PHP-кода внутри tiff-изображения.
Я делаю свой собственный сценарий загрузки изображений, и я предполагаю, что мне придется защищаться от этой возможности. Кроме того, я понятия не имею, как это будет работать. Кто-нибудь знает, как оболочка php, спрятанная внутри изображения, будет выполняться сама? Нужно ли его загружать определенным образом?
Благодарю.
Повторная кодировка изображения не заставит кого-то загружать оболочку. Единственный верный способ предотвратить его – перекодировать и сканировать изображение на наличие тэгов php.
Пример оболочки PHP PNG, которая выдержит повторное кодирование
Да, его нужно будет загружать, возможно, с помощью предоставленной пользователем переменной во включенном пути, например:
include('templates/' . $_GET['page']); Они также могли бы позволить пользователю установить полное имя файла с расширением .php, поэтому все, что им нужно сделать, это загрузить его в браузере.
Убедитесь, что getimagesize() не возвращает false, использует произвольное имя файла и принудительно getimagesize() расширение файла. Если это вообще возможно, не сохраняйте загруженное изображение в доступном в Интернете месте, так как оно также может содержать JS и, следовательно, быть вектором XSS.
Повторное кодирование изображения также позволяет вам удалять неприятные метаданные и мусор в конце, что разрешено несколькими форматами (например, JPEG)
Есть некоторые способы защитить себя от таких трюков. Проверьте их здесь
Также прочитайте эту статью, которая объясняет атаку и способы ее решения.
Главное в этом – использование функции basename php для отсрочки таких атак.
Я знаю, что есть способ (или был) способ сохранить php-файл как .gif и запустить его код. В эксплоите, который я видел на странице загрузки, тип mime был установлен как GIF, и изображение было загружено чем-то вроде: require('myimage.gif'); Когда myimage.gif был фактически файлом PHP, переименованным в .gif , в том числе файл выполнил бы полезную нагрузку php, иначе файл был просто нормальным gif. Я видел этот эксплойт для сценария загрузки, хакер также hex отредактировал 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 против myimage.php.gif , сохраняя загруженный файл в md5 (или имя rand) имени файла (исключая тип файла), поэтому myimage.php.gif станет ef0ca703846cdb7a0131ac2889304a27.gif
3) Проверьте целостность файла, убедитесь, что заголовок и остальная часть файла являются законными.
4) Не используйте require('myimage.gif'); вместо этого распечатать его содержимое
Если вы используете только функции GD для управления изображениями, вы должны быть в порядке. Чтобы быть в безопасности, вы можете конвертировать все входящие изображения в конкретный формат, который вы можете считать «безопасным» (мне нравится PNG или JPG, в зависимости от того, является ли вывод вывода браузером или каким-то высоким качеством -Распечатать). Кроме того, никогда не используйте имя imoage, предоставленное пользователем в вашей собственной файловой системе. Таким образом, он не сможет помещать странные данные в имя файла. Чтобы быть более безопасным, вы можете использовать утилиту преобразования imagemagik командной строки. Это быстрее и безопаснее.
Я не знаю об этом конкретном эксплойте, но обычно использует такие функции, используя ошибки в программном обеспечении, которое загружает изображение. Если PHP или, точнее, библиотека, загружающая изображение TIFF, выделяет неправильный объем памяти для хранения изображения, он может попытаться загрузить изображение в меньшем объеме памяти, чем зарезервировано. Это называется переполнением буфера.
Это также означает, что часть изображения загружается в кусок памяти, который не выделяется для изображения. Эта часть может быть выполнена, потому что она действительно может быть зарезервирована для кода.
Эти проблемы могут возникнуть, если в библиотеке изображений есть ошибка. Я думаю, что такая ошибка существует для GIF в IE 5. Объем выделенной памяти не определялся фактическим размером файла, а информацией о размере файла в заголовке файла. Это позволило людям создавать поврежденные файлы gif, заканчивая фрагментом кода, который был написан в сегменте кода процесса и может быть выполнен.
Мне пришло в голову блестящее решение.
Если вы сохраняете свои изображения на отдельном сервере / домене / CDN / независимо от того, у вас нет прямого доступа к вашему коду, вы выполнили свою миссию!
Да, оно может. Создайте файл tif (php-code.tif) со следующим кодом
<?php die("TIF file malicious code works");
Затем в другом скрипте make include 'php-code.tif' ;
Посмотрите сами, что происходит …
Да, это означает, что злоумышленник имеет доступ к вашему серверу или вы сами загрузили файл в качестве темы или плагина для cms … oups!
Теперь вторая часть для защиты от таких атак, но я не смог найти надежного решения, которое будет работать с большинством CMS и не будет включать в себя отказ в списках каталогов. Все еще смотрящий…
Если в обработке изображений PHP не возникает серьезной ошибки, я не вижу, как PHP-код в изображении может когда-либо интерпретироваться, просто работая с ним или отображая его.
Однако есть способы использовать изображения для атак Cross-Site-Scripting для пользователей, использующих Internet Explorer
Вы также должны быть осторожны, чтобы пользователи не могли загружать изображения, которые будут использоваться в качестве ввода PHP. Например. быть включенным () d по какой-либо причине или загружаться с расширением .php.
Apache Multiviews может даже привести к тому, что изображения с именем image.php.jpg будут выполнены при некоторых обстоятельствах (хотя я не уверен в этом).
Вы можете кодировать веб-оболочки в png-изображение, если вы это сделаете правильно, он также сможет пережить повторное кодирование.
взгляните на это