Чтение онлайн

<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 может быть осуществлена несколькими путями:

? проверка поля Referer POST-запроса может показать истинный сайт, с которого производился запрос, на основании этой проверки можно защититься от атаки;

? для каждой формы можно сформировать скрытое поле со сформированными секретными данными так, как мы делали это для GET-запросов. При отправке данных с формы скрытое поле также будет отправлено. Нам достаточно просто проверить соответствие переданных данных со сформированными на сервере, чтобы убедиться в том, что POST-запрос безопасен.

ASP.NET MVC содержит вспомогательный набор инструментов для реализации второго сценария защиты от CSRF-атак. Инструменты представляют собой метод расширения Html.AntiForgeryToken, который формирует скрытое поле в разметке:

<% using (Html.BeginForm) { %>

... // здесь набор элементов управления

<%= Html.AntiForgeryTokenO %>

<input type="submit" value="Change Password" />

<% } %>

На примере показано использование метода расширения Html.AntiForgeryToken, который в результате сформирует следующую разметку: