Загрузка изображения - проблемы безопасности
Я разрабатываю веб-приложение ASP.NET и хотел бы, чтобы пользователь смог или загрузить изображение от их локальной системы или передачу в URL к изображению. Изображение может или быть JPG или PNG. Какие проблемы безопасности я должен быть обеспокоен выполнением этого? Я видел различные способы встроить код в файлах JPG. Есть ли какие-либо методы в C# (или внешние библиотеки), который может подтвердить, что файл является JPG/PNG, иначе бросьте ошибку? По крайней мере я делаю каталог, который содержит загруженные изображения, недоступные для просмотра и помещающие макс. предел размера 1 МБ, но я хотел бы реализовать дальнейшие проверки.
Спасибо за любой совет.
3 ответа
Существуют ли какие-либо методы в C # (или внешних библиотеках), которые могут подтвердить, что файл является файлом JPG / PNG, иначе выдаст ошибку?
Может быть, но это само по себе не помогает. Вы можете легко создать файл, который является одновременно допустимым форматом изображения и , содержащим активное содержимое HTML / сценария, на которое можно наткнуться при сниффинге содержимого IE. Или же следует беспокоиться о неработающих политиках происхождения Java и Flash, которые могут иметь тот же эффект, что и сценарии в контексте безопасности вашего сервера.
Если вы обрабатываете изображение (например, кадрируете, изменяете размер) и повторно сохраняете, это очень и очень затрудняет проведение атак контрабанды контента. Однако вы всегда должны убедиться, что ваши серверные инструменты обновлены, поскольку уязвимости в библиотеках обработки изображений могут подвергнуть вас эксплойту на стороне сервера.
Если вы не можете этого сделать, лучшим решением для устранения всех проблем с внедрением контента будет обслуживание изображений из другого [под] домена, не имеющего доступа ни к одной из конфиденциальных учетных данных (файлы cookie, базовая авторизация) основного сайта.
Если для этой цели используется субдомен, например
images.example.com, ваш основной сайт должен быть доступен только с с поwww.example.comи с , но не сexample.com. В противном случае контент, введенный вimages.example.com, может получить доступ к файлам cookie дляexample.comв IE.example.comследует 301-редирект наwww.example.com, чтобы предотвратить нежелательную утечку файлов cookie в целом.Добавьте заголовок
X-Content-Type-Options: nosniffк ответу, чтобы заблокировать атаки контрабанды контента из IE8. (Увы, это не помогает с более ранними версиями.)
Также:
Очистка имен файлов, указанных пользователем, является жесткой , особенно если ваше приложение, вероятно, работает на сервере Windows, где действуют правила использования имена файлов действительно сложны. Хорошее место для начала - разрешить использование только буквенно-цифровых символов и добавить собственное расширение файла и префикс. (Префикс необходим, чтобы избежать зарезервированных имен файлов Windows и пустого имени файла.)
Лучше: сохранить указанное пользователем имя файла в базе данных, а не использовать его как настоящее имя файла.
См. этот вопрос для более подробного обсуждения проблем безопасности загрузки файлов.
Не позволяйте пользователю определять имя файла который будет использоваться на вашем сервере. Вместо этого используйте [сгенерированный guid] .jpg и поместите имя файла, которое они использовали, в таблицу базы данных, если вам это нужно.
См. № 12 здесь: http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html
Внешний контроль имени файла или пути Когда вы используете ввод постороннего человека при создании имени файла, результирующий путь может указывать за пределы предполагаемого каталога. Злоумышленник может объединить несколько последовательностей ".." или похожих , чтобы заставить операционную систему выйти из каталога с ограниченным доступом .Другие атаки, связанные с файлами, упрощаются за счет внешнего управления именем файла, такого как переход по символической ссылке, которая заставляет ваше приложение читать или {{1} }} изменять файлы, к которым злоумышленник не может получить доступ напрямую. То же самое применимо, если ваша программа работает с повышенными правами и принимает имена файлов в качестве входных данных . Аналогичные правила применяются к URL-адресам и разрешают постороннему указывать произвольные URL-адреса.
Также будьте осторожны с URL-адресом, убедитесь, что это абсолютный внешний URL-адрес, чтобы они не могли использовать ваш собственный веб-сервер для копирования конфиденциального файла из вашей локальной сети в область, где они могут получить к нему доступ, поскольку вы будете загружать этот URL-адрес из кода, запущенного на вашем веб-сервере.
Это абсолютное минное поле. Кое-что следует принять во внимание (не обязательно исчерпывающий список, никаких гарантий и т. д.).
- Некоторые люди используют regexs для разбора, поэтому нет способа узнать, содержит ли файл код. ZIP-файлы имеют свой каталог в конце. Sun/Oracle Java PlugIn/WebStart теперь проверяет, что файл начинается с магического номера локального заголовка/входа ZIP, чтобы избежать атак "GIFAR".
- Подача с другого домена, чтобы избежать проблем с одинаковым происхождением.
- Подача с другого IP-адреса, чтобы избежать проблем с одноименными источниками.
- Немного сложно проверить, использует ли файл, скажем, переполнение буфера 0-дня. Он может даже использовать бесконечный цикл для создания DoS.
- Лучше всего перекодировать изображение.
- Будьте осторожны с URL/именем пути к файлу. Если вы предоставляете такую возможность, используйте проверку белого списка. В частности, символы NUL являются "забавой". См. также атаки обхода каталога. Вообще, возможность поместить файл с заданным содержимым в известное место - это, по меньшей мере, большой обман.
- При работе с изображениями вы можете захотеть проверить, что их размер вменяем. Декомпрессия огромного изображения вполне может привести к DoS. Также обратите внимание, что алгоритмы сжатия часто позволяют сжимать тривиальные данные на огромные коэффициенты.