Санировать HTML прежде, чем сохранить в DB или перед рендерингом? (Библиотека AntiXSS в ASP.NET)
У меня есть редактор, который позволяет пользователям добавить HTML, который хранится в базе данных и представляется на веб-странице. Так как это - недоверяемый вход, я планирую использовать Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment санировать HTML.
- Должен я santiize прежде, чем сохранить к базе данных или прежде, чем представить недоверяемый вход в веб-странице?
- Существует ли преимущество во включении исходного кода AntiXSS в моем проекте вместо просто DLL? (Возможно, я могу настроить белый список?)
- Какой файл класса должен я заглядывать для фактической реализации GetSafeHtmlFragment
4 ответа
Я не согласен с выбранным ответом по двум причинам
- Если вы сохранили закодированные данные, вы должны выбрать кодировщик перед сохранением. Что произойдет, если вы сохранили что-то как HTML, но также хотите отправить это в другом формате, например, как ответ JSON или как часть XML-документа? Теперь у вас есть HTML-кодированный формат, который вы должны декодировать, а затем кодировать в правильном формате.
- Что, если мы обнаружим ошибку в кодировщиках и выпустим новую версию? Теперь, поскольку вы не кодируете в момент вывода, все ваши старые данные могут содержать вещи, которые были неправильно закодированы. Вы можете кодировать снова, но тогда вы столкнетесь с проблемами двойного кодирования, которые может быть болезненно отфильтровать правильно.
Обычно вы кодируете в точке вывода и обрабатываете любые данные, поступающие из хранилища данных, как ненадежные по умолчанию - в конце концов, что, если кому-то удастся отредактировать вашу базу данных напрямую или с помощью SQL-инъекции?
- Both
- Only if you plan on change it, which I would not do personally
- The AntiXss class (так как он называется как
AntiXss.GetSafeHtmlFragment())
Вы можете использовать в директиве страниц параметр ValidateRequest = «TRUE» . Таким образом, все данные запроса подтверждены, и если есть проблема проверки, вы всегда можете поймать ошибку. Это также предотвращает инъекционные потоки SQL и другие не только возможные XSS.
С числовыми данными вы можете проверить целочисленное переполнение или неправильное использование типов данных с Int32.triparse () или любым другим из семейства TryParse (Byte.triparse int16.triparse ...)
Нет необходимости использовать любой другой Класс или дополнительный метод Sanitizer.
Послушайте подкаст 67 OWASP 67 с Джеффом Уильямсом по XSS . Он говорит о запрете дезинфекции или кодирования перед хранением. Основная причина в том, что если (когда) библиотеки будут развиваться в ответ на новые уязвимости, ваши данные снова застрянут в старой версии. Конечно, это не мешает вам запускать какие-либо данные в белом списке в точке входа и отклонять все, что выходит за пределы допустимого диапазона.