Межсайтовый скриптинг и кодирование HTML

Question

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

Кроме того, есть ли инструмент / продукт, который очистит мой пользовательский ввод для меня, так что мне не придется писать свои собственные процедуры.

Answer 1

В этом вопросе есть различные тонкости, хотя в целом ответ да.

• Безопасность вашего сайта в значительной степени зависит от того, где вы размещаете данные. Если вы поставите его как правильный текст, у злоумышленника не будет возможности выполнить XSS. Если вы поместите его в атрибут, если вы забудете экранировать кавычки или не будете проверять многобайтовую корректность, у вас будет возможная атака. Если вы поместите его в переменную JSON, неправильное экранирование может привести к произвольному JavaScript. И т.д. и т.п. Контекст очень важен.

• Другие пользователи предложили использовать функции удаления XSS или обнаружения XSS. Я склонен считать удаление XSS недружелюбным для пользователя; если я отправлю адрес электронной почты, например , и ваша функция удаления XSS считает, что это HTML-тег, этот текст загадочным образом исчезнет. Если я работаю на дискуссионном форуме XSS, я не хочу, чтобы образец кода людей был удален. Обнаружение немного более разумно; Если ваше приложение может определить, кто его атакует, оно может заблокировать IP-адрес или учетную запись пользователя. Вы должны быть осторожны с такого рода функциональностью, однако; невинные могут и попадут под перекрестный огонь.

• Проверка - важная часть логики веб-сайта, но она также не зависит от экранирования. Если я ничего не проверю, но буду избегать всего, XSS-атак не будет, но кто-то может сказать, что их день рождения - «день, когда умерла музыка», и приложение не будет мудрее. Теоретически, достаточно строгая валидация для определенных типов данных может выполнять все обязанности по экранированию (например, числа, перечисления и т. Д.), Но в общем случае рекомендуется избегать их глубокой защиты. Даже если вы на 100%, это целое число. Это не может быть.

• Выход из открытого текста - тривиальная проблема; если ваш язык не дает вам функции, строковая замена для <, >, ", ' и & с соответствующими им сущностями HTML сделает свое дело. (Вам нужны другие сущности HTML, только если вы не используете UTF-8). Разрешение тегов HTML нетривиально и требует отдельного вопроса переполнения стека.

Answer 2

кодирование вашего HTML - это начало ... оно не защищает от всех атак XSS.

Если вы используете PHP, вот хорошая функция, которую вы можете использовать на своих сайтах: Функция RemoveXSS () Каллахара

Если вы не используете PHP, по крайней мере, код хорошо прокомментирован, объясняя назначение каждого раздела, и затем может быть адаптирован к другому языку программирования.

Answer 3

Ответ - нет, кодировки не достаточно. Наилучшей защитой для XSS является сочетание проверки «белого списка» всех входящих данных и соответствующего кодирования всех выходных данных. Проверка позволяет обнаруживать атаки, а кодирование предотвращает запуск любого успешного сценария в браузере. Если вы используете .NET, вы можете проверить эту библиотеку http://msdn.microsoft.com/en-us/library/aa973813.aspx

Вы также можете проверить некоторые Шпаргалки, чтобы проверить свою защиту: http://ha.ckers.org/xss.html

С уважением,

Victor

Answer 4

Ввод HtmlEncoding дает вам хорошую часть пути, не позволяя HTML отображаться на странице.

В зависимости от вашего языка там должны существовать элементы для очистки данных. В .NET вы можете использовать Server.HtmlEncode (txtInput.Text) для ввода данных из текстового поля с именем txtInput.

Как уже упоминалось, для истинной защиты необходимо больше предметов.