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

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

8 голосов
/ 14 января 2010

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

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

Ответы [ 4 ]

32 голосов
/ 24 февраля 2010

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

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

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

11 голосов
/ 26 мая 2010

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

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

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

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

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

...