Разбитые изображения в XSS-атаках

Question

Многие веб-сайты обсуждают испорченные изображения как хорошие признаки возможной атаки XSS в исходном коде страниц. Мой вопрос: почему так много злоумышленников позволяют этому случиться? Похоже, что злоумышленнику будет гораздо сложнее использовать iframe или скромную картинку, чтобы скрыть свой постоянный сценарий. Я могу ошибаться, полагая, что испорченные изображения очень распространены в XSS. Спасибо за помощь!

Редактировать: Я думаю, что XSS может быть неправильным в этом случае. Я понимаю, почему тег изображения, который указывает на файл сценария Java, не будет отображаться и будет слишком много проблем для отображения. Я думаю, что мой вопрос больше связан с экземплярами файлов, загруженных на сервер с вредоносным кодом в них. Я полагаю, что на самом деле это своего рода второй вопрос - действительно ли это XSS или более похоже на использование небезопасных ссылок на объекты сервером (в соответствии с терминами OWASP)?

Редактировать: Вот хорошая статья , подробно описывающая XSS. В нем упоминаются неработающие изображения, но также обсуждается, как их избежать. Я не могу найти никаких статей, упоминающих конкретные атаки с испорченными изображениями. Однако я вспоминаю, что читал о нескольких фишинговых атаках по электронной почте (в этих случаях вы абсолютно правы в отношении CSRF, Даниэль.

Answer 1

Веб-сайты, которые вы читали, могут ссылаться на атаки подделки межсайтовых запросов (CSRF; CWE-352 ). CSRF-атаки обычно выполняются с «поврежденными изображениями», потому что (1) браузеры автоматически загружают изображения (таким образом, браузер автоматически делает HTTP-запрос от имени посетителя) и (2) многие веб-сайты позволяют пользователям добавлять изображения в контент, добавленный пользователями. .

Представьте, что веб-сайт позволяет пользователям оставлять комментарии в блоге, а программное обеспечение блога позволяет пользователям добавлять изображения к своим комментариям, указав URL-адрес изображения. Вероятно, существуют различные функции администратора программного обеспечения блога, которые вызываются по запросу определенных URL-адресов. Например, комментарий может быть удален любым, кто вошел в систему как администратор, если администратор «посетил» /comments/delete/# (где «#» - это идентификатор конкретного комментария, который нужно удалить). Вредоносный неадмин не сможет удалить комментарий, скажем, комментарий 7754, посетив /comments/delete/7754, потому что он или она не аутентифицирован. Однако злонамеренный пользователь может попытаться добавить новый комментарий с содержимым, состоящим только из «изображения» на /comments/delete/7754. Если администратор впоследствии просматривает комментарий (просто просматривает страницу, содержащую комментарий злоумышленника), то браузер автоматически запросит «изображение» на /comments/delete/7754. Это может привести к удалению комментария 7754, поскольку администратор вошел в систему.

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