Внешне связанные изображения - Как предотвратить межсайтовый скриптинг

Question

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

Мои текущие сообщения о безопасности в настоящее время таковы, что как при сохранении, так и при открытии весь контент кодируется. Я использую asp.net (c #) на сервере и много jquery на клиенте для создания элементов пользовательского интерфейса, включая генерацию тегов изображений.

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

Answer 1

Проверка файла действительно, изображение не поможет.Злоумышленник может вернуть одну вещь, когда сервер запрашивает, и другую, когда потенциальная жертва делает тот же запрос.

Сказав это, до тех пор, пока вы ограничиваете URL-адрес, будет напечатан только внутри атрибута src imgтэг, тогда у вас есть недостаток CSRF, но не XSS.

Кто-то может, например, создать URL-адрес «image» в виде: http://yoursite.com/admin/?action=create_user&un=bob&pw=alice Или, более реалистично, но более раздражающе;http://yoursite.com/logout/

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

Но вернемся к вашему вопросу;если нет какой-то текущей ошибки браузера, я не могу думать о том, что у вас не будет XSS.О, не забудьте убедиться, что URL-адрес их изображения не содержит нечетных символов.то есть: URL изображения "><script>alert(1)</script><!- - может иметь плохие последствия.Я полагаю, вы знаете, что избежать этого.

Answer 2

Ваш подход к безопасности неверен. Не подходите к теме как «У меня есть пользовательский ввод, так как я могу предотвратить XSS». Скорее подходите к этому так: «У меня есть пользовательский ввод - он должен быть как можно более ограничительным, то есть ничего не пропускать». Затем, основываясь на этом, разрешите только то, что абсолютно необходимо - строки простого текста, тщательно очищенные для предотвращения чего-либо, кроме URL-адреса, и специальные необходимые символы только для URL-адресов. Тогда, как только это продезинфицировано, я должен только позволить изображениям. Проверить это сложно, потому что его легко обмануть. Однако, это все еще должно быть проверено на. Тогда, поскольку вы используете поле ввода, вы должны убедиться, что все, от сценариев JavaScript и escape-символов, HTML, XML и SQL-инъекций, все преобразовано в открытый текст и обезврежено и бесполезно. Считайте своих пользователей идиотами и хакерами - они будут вводить все неправильно и пытаться взломать что-то в вашем поле ввода.

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