Новый улучшенный AntiXss 3.1 - теперь с функцией санитарной обработки
Всем привет! С вами Браэн Салливан!
Как уже много раз обсуждалось, SDL предполагает использование библиотеки Microsoft AntiXss library, которая обеспечивает защиту от атак методом межсайтового скриптинга. Тем не менее ни разу не рассматривалась следующая проблема: существуют две различные версии AntiXss: одна в свободном доступе для сторонних пользователей и вторая, доступная только для использования внутри серверных информационных центров Майкрософт. Обе версии обладали функцией кодирования выходных данных HTML, чтобы инфицированный скрипт воспринимался браузером как безвредный текст и не выполнялся на компьютере пользователя. При этом внутренняя версия Майкрософт дополнительно обладала функцией санитарной обработки входящих данных пользователя и отсеивания потенциально опасных скриптов.
Мы всегда хотели открыть эту технологию для сообщества сторонних разработчиков, поэтому я крайне рад сообщить, что команда Information Security Tools включила функциональность санитарной обработки HTML в новую публичную версию AntiXss (AntiXss 3.1) и выпускает целую библиотеку под лицензией открытого кода MS-PL. Давайте слегка подробнее рассмотрим новую функциональность AntiXss 3.1 и те случаи, когда это функциональность будет вам полезна!
При правильном использовании кодирование выходных данных помогает предотвратить атаки межсайтового скриптинга (XSS). Тем не менее побочным эффектом данной методики является эффективность ее также и для предотвращения всех типов уязвимостей скриптов пользовательской HTML разметки, будь то вредоносных или полезных.
Ведь ясно, что “<script>document.location='evil.com'</script>” должно быть заблокировано.А что насчет “I like <b>strong</b> coffee”? Такая запись в любом случае не является вредоносной, и блокировать ее было бы уже чересчур. (Я оставлю на ваше усмотрение решение того, является ли вредоносным использование тега выделения в различных обстоятельствах)
До сих пор предпочитаемым путем решения проблемы выборочного разрешения только определенных HTML-тегов наподобие <b> или <i>, было следующим: свести входные данные к регулярным выражениям и проверить, что они содержат только подходящие символы и цифры Юникода и заранее определенные теги. К примеру, это может выглядеть так:
Этот подход с одной стороны предотвращает нежелательные теги, с другой он блокирует все атрибуты разрешенных тегов. Иногда это даже хорошо : ведь нападающий может прикрепить вредоносный скрипт на атрибут наведения указателя мыши onmouseover тегов <b> или <i> , но блокирование чрезмерно и иногда не позволяет выполняться полезным атрибутам, таким как язык lang и заголовок title. В теории возможно расширить регулярные выражения для использования подобных безопасных HTML-тегов и их атрибутов, но на практике подобные регулярные выражения окажутся неимоверно сложными как для разработки, так и для эксплуатации.
Новый AntiXss 3.1 берет все проблемы разметки на себя, реализуя тот же самый технический подход: он фильтрует все входящие данные, сохраняя только те скрипты и атрибуты, которые содержатся в списке "хороших" скриптов и удаляет все остальное. Необходимо просто пропустить сомнительные входящие HTML-данные через метод AntiXss.GetSafeHtml или GetSafeHtmlFragment, чтобы использовать функцию санитарной обработки:
1: string output = AntiXss.GetSafeHtml(input);
Я настоятельно рекомендую каждому скачать новый AntiXss 3.1 и использовать в ваших приложениях начиная с сегодняшнего дня! Это очень эффективное средство защиты, в особенности при использовании совместно с кодированием выходных данных(что было частью AntiXss с самого начала). Тем более что схема SDL предполагает использование этих двух методов обеспечения безопасности .
В заключении, я хотел бы поблагодарить команду Exchange team (чья библиотека HtmlToHtml обеспечивает логику санитарной обработки) и команду Information Security Tools , которая открыла эту функциональность для общественности, где она сможет принести максимальную пользу максимальному числу людей!
Перевод : Антон Зайцев