Безопасное обслуживание изображений

Я подозреваю, что ваш друг имеет в виду не просто показ изображений, а конкретно показ предоставленных пользователями изображений. Существует ряд проблем с безопасностью при обслуживании контента, предоставленного пользователями. В случае с изображениями существует несколько способов использовать загрузку изображения, чтобы заставить веб-сервер выполнить код. Некоторые из наиболее известных включают в себя:

• Файл "GIFAR". По сути, это файл GIF и объединенный файл jar. Поскольку информация индекса для GIF находится в начале, а для файла jar — в конце, два типа файлов можно объединить, и в результате получится как действительный GIF, так и действительный JAR.
• Несколько расширений файлов. Веб-серверы поддерживают несколько расширений файлов, что позволяет использовать такие вещи, как интернационализация. Например, файл с именем page.html.fr может сопоставляться с версией страницы на французском языке. Файл с расширением image.php.jpg или даже image.php.123 может исполняться как скрипт PHP, в зависимости от конфигурации сервера.
• Переполнение буфера. Форматы файлов изображений обычно содержат заголовок в начале, который описывает размер и формат файла. Занижение размера может позволить злоумышленникам создать атаку переполнения буфера.

Все эти примеры приводят к возможности выполнения кода в качестве веб-сервера. Хотя функциональность сайта требует возможности загружать файлы, их хранение в каталогах, к которым нет прямого доступа по URL-адресу, затрудняет их использование. Точно так же использование сценария для их обслуживания, а не обработчиков MIME веб-сервера, гарантирует, что изображения будут обрабатываться как поток данных, а не как потенциально исполняемый файл.

Насколько смешна такая безопасность, зависит от количества пользователей, характера собираемых о них данных и тривиальности веб-сайта. Как минимум, злоумышленник хотел бы получить пароли пользователей из-за стремления их синхронизировать. Пользователь на вашем сайте с паролем ABC123, вероятно, будет использовать тот же пароль для электронной почты, социальных сетей и, возможно, банковских и финансовых сайтов. Помимо паролей, если данные, которые вы собираете о своих пользователях, позволяют установить личность или имеют другую рыночную стоимость, или если у вас просто большое количество пользователей, вы должны предположить, что сайт будет целью. Это означает, что нужно либо более внимательно относиться к предоставленным пользователем файлам изображений, либо тщательно их проверять, либо и то, и другое.

У меня нет хорошего ответа на вопрос, решит ли использование imagemagick проблемы безопасности. По крайней мере, обязательно используйте актуальную версию, потому что быстрый поиск выявил ряд известных уязвимостей. Помните, что файлы, о которых вам нужно беспокоиться, могут взорвать imagemagick, даже если они не используют одну из известных уязвимостей, поэтому убедитесь, что у вас есть ДЕЙСТВИТЕЛЬНО хороший отлов ошибок.

Если изображения не являются частными, т. е. вы можете легко их увидеть, вы просто не хотите, чтобы кто-то читал их все по своему желанию, может быть достаточно присвоения каждому из них уникального имени.

Если их больше нескольких тысяч (и это кажется вероятным), то создание иерархии каталогов, в которой они хранятся, также может помочь ускорить доступ, увеличив при этом пространство поиска настолько, что они не будут найдены случайным поиском. Например: файл с именем 347168a5d9b4ac5eb386e396f68b2231.jpg можно поместить в каталог: /images/34/71/68/347168a5d9b4ac5eb386e396f68b2231.jpg Многоуровневый каталог ускоряет доступ, избегая сканирования тысяч записей каталога и рандомизированного имени ( хранится в базе данных, прикрепленной к пользовательскому списку изображений в галерее), предотвращает поиск случайных файлов.

Накладные расходы такого сценария звучат смешно.

То же самое. Если изображения находятся в открытом доступе, я не вижу абсолютно никаких причин для этого.

Если они не общедоступны (т. е. должны быть доступны только для зарегистрированных пользователей), то нет другого способа, как описывает ваш коллега (или с помощью X-Sendfile после выполнения проверки входа, что частично накладных расходов, если установлено необходимое программное обеспечение). Но если это не так, накладные расходы, необходимые для этого, сумасшедшие.

Если вы решили, что вам действительно нужно, чтобы изображения были в безопасности, то вот что я использовал в проекте комиксов (в основном я помещал тонны комиксов в каталог, а затем, когда наступало время, я разрешал доступ к ним один за раз)

//check if image should be accessed by the current request...

$fh=fopen($my_image,"rb");

if($fh==NULL){
        exit();
}
rewind($fh);
header("Content-Type: image/png");
header("Content-Length: " . filesize($fn));
fpassthru($fh);

fclose($fh);
exit();