Санитарная обработка представленных URL

Question

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

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

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

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

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

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

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

Answer 1

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

При этом все еще существуют проблемы безопасности с фотографиями с внешними ссылками:

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

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

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

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

Answer 2

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

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