Как я защищаю от атак XSS в таких атрибутах, как src?

c# html-agility-pack security xss

Вопрос

Поэтому я создавал дезинфицирующее средство C # html, используя html-маневренность с белым списком. Он отлично работает, за исключением таких случаев:

<img src="javascript:alert('BadStuff');" />
<img src="jav&#x09;ascript:alert('BadStuff');"> 

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

Принятый ответ

Атаки межсайтового скриптинга (XSS) используют уязвимости в проверке веб-страниц путем ввода кода сценария на стороне клиента. Общие уязвимости, которые делают ваши веб-приложения восприимчивыми к межсайтовым сценариям атаки, включают в себя неспособность правильно проверить ввод, неспособность кодировать вывод и доверять данным, полученным из общей базы данных. Чтобы защитить ваше приложение от атак межсайтовых скриптов, предположите, что все входы вредны. Ограничьте и подтвердите все входные данные. Кодировать все выходные данные, которые могут включать потенциальные символы HTML. Сюда относятся данные, считанные из файлов и баз данных.

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

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

  • Неспособность ограничить и подтвердить ввод.
  • Ошибка при кодировании вывода.
  • Доверие к данным, полученным из общей базы данных.

Методические рекомендации

Двумя наиболее важными контрмерами для предотвращения межсайтовых сценариев являются:

  • Ограничить ввод.
  • Кодировать вывод.

Резюме шагов

Чтобы предотвратить межсайтовый скриптинг, выполните следующие шаги:

Шаг 1. Проверьте, включена ли проверка запроса ASP.NET.

Шаг 2. Просмотрите код ASP.NET, который генерирует вывод HTML.

Шаг 3. Определите, содержит ли вывод HTML входные параметры.

Шаг 4 . Просмотрите потенциально опасные HTML-теги и атрибуты.

Шаг 5 . Оценить контрмеры.

Подробные сведения см. В 2-й ссылке.

Рекомендации:

Межсайтовый скриптинг объясняется: Как предотвратить атаки XSS

Практическое руководство. Предотвращение межсайтовых сценариев в ASP.NET


Популярные ответы

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

Белый список, который вы упомянули, является первым шагом (и важным в этом). Чтобы реализовать белый список, просто вычеркните каждый символ, который недействителен для URL-адреса. Также убедитесь, что URL-адрес правильно сформирован, что означает, что он указывает на действительный ресурс, к которому должен иметь доступ пользователь. Например, пользователь не должен получать доступ к локальному файлу на сервере, передавая file://sensitive.txt или что-то в этом роде. Если http или https являются единственными протоколами, которые следует использовать, убедитесь, что URL-адрес начинается с них. Если вы являетесь дополнительным параноиком, вы можете полностью отклонить этот запрос, поскольку очевидно, что он был подделан. «Белый список» важен, но, тем не менее, использование белых списков не обеспечит безопасность этой функции.

Канонизация важна, потому что многие атаки зависят от отправки URL-адресов, которые в конечном итоге переносят вас в определенное место, но могут злоупотреблять врожденным отсутствием рассуждений компьютера, чтобы получить то, что не должно. Это также поможет устранить дублированные пути к одному и тому же ресурсу, который может повысить производительность (или, по крайней мере, позволит вам повысить производительность, не перепроверяя известный файл, который не изменился с момента последнего его проверки). Будьте осторожны с этим, потому что можно обмануть последнюю измененную дату, чтобы злоумышленник мог поменять вредоносный файл после того, как вы уже «проверили и доверили» его).

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



Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему
Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему