Санировать HTML перед сохранением в БД или перед рендерингом?(Библиотека AntiXSS в ASP.NET)

Question

У меня есть редактор, который позволяет пользователям добавлять HTML-код, который хранится в базе данных и отображается на веб-странице.Поскольку это ненадежный ввод, я планирую использовать Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment для очистки HTML.

• Должен ли я санировать перед сохранением в базе данных или перед отображением ненадежных входных данных на веб-странице?
• Есть ли преимущество включения в мой проект исходного кода AntiXSS вместо только DLL?(Может быть, можно настроить белый список?)
• Какой файл класса мне следует искать для фактической реализации GetSafeHtmlFragment

Answer 1

Я не согласен с выбранным ответом по двум причинам

1. Если вы сохранили закодированные данные, вам необходимо выбрать кодировщик перед сохранением.Что произойдет, если вы сохранили что-то в формате HTML, но хотите передать это в другом формате, например, как ответ JSON или как часть документа XML?Теперь у вас есть формат HTML, который вы должны декодировать, а затем закодировать в правильный формат.
2. Что, если мы обнаружим ошибку в кодировщиках и выпустим новую версию?Теперь, поскольку вы не кодируете в момент вывода, все ваши старые данные могут содержать элементы, которые были закодированы неправильно.Вы можете снова закодировать, но тогда вы столкнетесь с проблемами двойного кодирования, правильная фильтрация которых может оказаться затруднительной.

Обычно вы кодируете в момент вывода и обрабатываете любые данные, поступающие из хранилища данных, по умолчанию как ненадежные — в конце концов, что, если кому-то удастся отредактировать вашу базу данных напрямую или с помощью SQL-инъекции?

Answer 2

Послушайте Подкаст OWASP 67 с Джеффом Уильямсом на XSS.Он говорит о том, что перед хранением нельзя проводить дезинфекцию или кодирование.Основная причина заключается в том, что если (когда) библиотеки будут развиваться в ответ на новые уязвимости, ваши данные останутся в старой версии.Конечно, это не мешает вам проверять любые входные данные в белом списке в точке входа и отклонять все, что выходит за рамки допустимого диапазона.

Answer 3

• Оба
• Только если вы планируете его изменить, чего лично я бы не сделал.
• Класс AntiXss (поскольку он называется AntiXss.GetSafeHtmlFragment())

Answer 4

Вы можете использовать в директиве страницы параметр Валидатерекуест="истина".Таким образом, все данные запроса проверяются, и если возникает проблема с проверкой, вы всегда можете обнаружить ошибку.Это также предотвращает потоки внедрения sql и другие, не только возможные XSS.

С числовыми данными вы можете проверить целочисленное переполнение или неправильное использование типов данных с помощью Int32.TryParse() или любого другого из семейства TryParse (Byte.TryParse Int16.TryParse...)

Нет необходимости использовать какой-либо другой класс или дополнительный метод дезинфекции.