Шрифт:
<div>
<%= Html.Encode("<script>alert('Атака удалась')</script>") %>
</div>
Очевидно, что если вывести строку, содержащую тег <script>, то она будет интерпретироваться браузером как JavaScript-код и ее содержимое выполнится. Но используя Html.Encode, мы получаем возможность избежать атаки. Результатом работы этой функции станет следующий текст разметки:
<div>
<script>alert('Атака удалась')</script>
</div>
Как можно убедиться, метод расширения Html.Encode декодировал опасную строку в такую последовательность, которая выводится браузером как обычная строка текста, безопасная для клиентов.
При работе с Ajax иногда возникает необходимость возвращать данные в виде HTML-разметки, содержащей пользовательские данные. Это может привести к нарушению безопасности и атаке описанной ранее. Для предварительной обработки данных в действиях контроллера можно использовать методы статического класса Httputility. Httputility содержит массу методов для большинства сценариев обработки потенциально опасных данных: HtmlEncode, HtmlAttributeEncode, UrlEncode, UrllPathEncode.
Для более надежной защиты и предоставления дополнительного функционала Microsoft предлагает разработчикам бесплатную библиотеку AntiXSS, которая на момент написания книги имела версию 3.1 (библиотека доступна по адресу. Данная библиотека обеспечивает еще более надежное декодирование потенциально опасных данных для обеспечения повышенных требований к безопасности. Кроме того, AntiXSS содержит полезные методы для разнообразных сценариев работы с данными и HTTP-модуль, который позволяет комплексно решать вопросы безопасности для проекта.
Управление данными и cookie
Применение cookie для сохранения информации используется веб-ресурсами очень часто. Практически каждый ресурс реализует с помощью cookie возможность автоматической авторизации пользователя, если он пожелал этого при первой авторизации. Каждый из вас наверняка знает все эти галочки "запомнить меня" на разнообразных ресурсах, которые здорово помогают пользователям, т. к. позволяют не тратить им время и нервы на ввод данных логина, пароля, а порой и замысловатой CAPTCHA-строки.
Однако следует знать, что использование cookie может привести к уязвимости сайта и к раскрытию пользовательских данных. Представим ситуацию: некоторый сайт производит обновление данных на базе строки запроса, полагаясь на произведенную авторизацию пользователя. И разумеется, данный сайт содержит современный механизм авторизации на базе cookie. Может сложиться впечатление, что это абсолютно безопасно, т. к. cookie хранится на компьютере пользователя, а обновление данных невозможно без подтвержденной авторизации. Однако здесь кроется ошибка, которая может привести к серьезному нарушению безопасности. Не будем предполагать, что cookie попросту может быть украден с компьютера пользователя, допустим, что вы предусмотрели такой вариант и кроме cookie проверяете еще и IP-адрес пользователя. Существует более простой вариант атаки и без доступа к cookie. Этот способ предполагает формирование на странице атакуемого сайта изображения с помощью доступного пользователям функционала. Только вместо адреса изображения злоумышленник может подставить строку запроса на модификацию данных. В таком случае все пользователи, зайдя на ресурс, при попытке просмотра картинки выполнят опасную строку запроса от своего имени. И в случае, если через строку запроса можно управлять данными, такой запрос может привести к печальным последствиям.
Мораль такова, что необходимо избегать управления пользовательскими данными через GET-запросы, которые формируются в том числе и строкой запроса. Все запросы, которые так или иначе приводят к модификации, созданию или удалению данных, необходимо оформлять через POST. Однако часто это очень неудобно для разработчика или вовсе невозможно. В таких случаях полезным будет следующее решение:
? для каждой пользовательской сессии формируется некая строка с уникальным значением;
? для всех запросов, которые модифицируют данные пользователя, добавляется некий параметр, содержащий сформированное уникальное значение, например, так:где параметр hash содержит секретное значение, полученное на сервере;
? в функционале, который занимается модификацией данных, производится проверка на переданное значение параметра, в случае если оно отсутствует или не соответствует созданному, предполагается нарушение безопасности;
? злоумышленник не сможет сформировать строку параметра безопасности, т. к. не знает ее, и описанная ранее атака не сможет быть произведена путем подмены строки запроса.
Однако POST-запросы тоже могут быть подвергнуты атаке. Так, злоумышленнику достаточно сформировать страницу в Интернете, где он создаст форму с автоматической отправкой данных на атакуемый сайт. Ничего не подозревающий пользователь, открыв такую страницу, скрытно для себя авторизуется на своем сайте, предоставляя злоумышленнику выполнять от его имени любые операции. Этот тип атаки получил название Cross-Site Request Forgery (CSRF).
Защита от CSRF может быть осуществлена несколькими путями: