Блог

У меня есть приложение webforms, которое позволяет пользователям отправлять URL-адреса изображений на сайт. Затем я просматриваю эти изображения в консоли администратора, прежде чем сделать их доступными на сайте для всеобщего обозрения. Им не обязательно отправлять изображение, это может быть ссылка на страницу, где содержится изображение.

Webforms защищает от вредоносного ввода по умолчанию, но только при вводе javascript в поле ввода. Таким образом, он мгновенно распознает такие вещи, как <script type="text/javascript">alert('nasty code');</script> но не http://www.nastysite.com/nastyScript.js , поскольку это просто URL, и «может» быть допустимым изображением.

в консоли администратора я перечисляю все отправленные в элементе управления datalist и использую элемент управления asp: Image для отображения изображения для проверки.

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

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

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

Я упускаю из виду какие-либо потенциальные недостатки?

Когда веб-браузер загружает ресурс как SRC тега IMG, он анализирует ответ в виде файла изображения. Если бы кто-то вместо этого отправил URL-адрес в файл JavaScript, результатом было бы просто поврежденное / отсутствующее изображение.

Тем не менее, по-прежнему существуют проблемы с безопасностью фотографий, связанных с внешними ссылками:

1. Как вы уже заявили, кто-то может поменять изображение постфактум, скажем, на pr0n.

2. Они смогут отслеживать IP-адрес, временную метку и идентификатор браузера всех посетителей вашего сайта, которые видят изображение. В зависимости от настроек браузера ваших посетителей, они также могут устанавливать файлы cookie для отслеживания ваших пользователей, когда они посещают как ваш сайт, так и другие, которые допускают аналогичные ссылки. Конечно, именно так работают практически все сервисы баннерной рекламы, работающие только с изображениями.

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

4. Теоретически они могли бы изменить файл изображения на ответ перенаправления 302 на какой-либо другой URL, который может вообще не быть изображением. Посетитель увидит только поврежденное изображение, но если у вас достаточно трафика, они могут использовать эти перенаправления, скажем, для выполнения DDoS-атаки на другом веб-сайте. (Я бы поместил это в категорию «паранойя».)

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

Что касается очистки входящих файлов — возможно ли проверить этот входящий файл во время загрузки и получить его тип содержимого или, возможно, даже его расширение и проверить его на соответствие списку хороших расширений. Например, пользователи могут отправлять изображения только в формате png, jpg и gif, возможно?