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

Question

Уважаемый коллега настаивает на том, что хранение изображений на моем сервере небезопасно, особенно если файловая структура легко догадывается (поскольку у нас есть галереи изображений, созданные пользователями, схему именования легко соблюдать).

Вместо этого он рекомендует хранить изображения над корнем и обслуживать их с помощью fread или fputthrough.

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

Я понимаю, что изображения должны быть проверены перед сохранением на сервере, и с этой целью я использую imagemagick для небольшого преобразования и сохранения в jpeg, что, насколько я понимаю, должно избавить от любых шлаков.

Итак, вопросы к великим умам по SO:

1. Есть ли проблемы с безопасностью при локальном хранении изображений с удобными для отслеживания путями?
2. Безопасен ли мой метод проверки изображений с помощью IM?
3. Есть ли причина использовать PHP для обслуживания изображений?
4. Действительно ли использование PHP связано с большими накладными расходами?
5. Будет ли использование CDN иметь значение с точки зрения безопасности (я НЕ хочу)?
6. Я что-то упускаю?

Всем спасибо!

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

<цитата>

Накладные расходы на такой скрипт звучат нелепо.

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

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

Answer 4

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

родовое слово