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

У меня есть редактор, который позволяет пользователям добавлять HTML, который хранится в базе данных и отображается на веб-странице. Поскольку это ненадежный ввод, я планирую использовать Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment для дезинфекции HTML.Санизировать HTML перед хранением в БД или перед рендерингом? (Библиотека AntiXSS в ASP.NET)

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

источник

2010-01-13 Nick

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

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

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

источник

2010-02-24 14:23:26 blowdart

Я вернулся и проголосовал за вас потому что я согласен с вашими аргументами, и ваше предложение соответствует рекомендации OWASP. Будем надеяться, что @ user102533 переключится и примет ваши. – David

Он не хранит закодированные данные, он хранит дезинфицированные данные - большая разница (это еще некодированный HTML) – orip

Точка 2 по-прежнему стоит (и да, я не уделял достаточного внимания при чтении!) Что делать, если в дезинфицирующем устройстве есть ошибка? Или вы хотите изменить правила санитарии? – blowdart

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

источник

2010-01-13 22:55:32 David

В базе данных уже есть код HTML, если я дезинфицирую его перед добавлением его в базу данных, тогда мне нужно дезинформировать уже существующие данные (для согласованности). Но есть ли какая-либо ценность в санировании перед добавлением его в базу данных? – Nick

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

+1 для санировки каждый раз, на всякий случай. Единственное, что нужно знать, это возможное поражение производительности, и в этом случае вы можете санировать только при сохранении в БД, но тогда вам нужно быть осторожным, чтобы вся информация в БД была действительно дезинфицирована. – orip

-1

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

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

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

источник

2010-01-13 23:06:37 backslash17

Проверка запроса включена по умолчанию, но вы слишком много верите в нее. Вы должны рассматривать его как один уровень безопасности, который дополняется верификацией белого списка в точке ввода (вы как бы трогали этот повторный синтаксический анализ) и кодирование вывода. Это также не поможет вам с точки зрения SQL Injection; утверждение «или 1 = 1» будет проходить прямо. Это может помочь вам объяснить это немного лучше: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html –

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

источник

2010-05-25 21:16:44

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

ответ

Смежные вопросы