Asp.net mvc framework
Шрифт:
<span id="message"></span>
</form>
</div>
Здесь определена стандартная форма для отправки данных на сервер. Для обработки работы формы и формирования Ajax-запроса необходимо переопределить поведение формы с помощью JavaScript. Далее представлен фрагмент кода, определяющий логику работы формы:
<script type="text/javascript">
$('document').ready(function {
$('#loginForm').submit(function(event) {
var postData = new Object;
postData.userName = $('#userName').val;
postData.password = $('#password').val;
postData.rememberMe = $('#RememberMe').is(':checked');
$.post('Account/LogOn',
postData,
function OnResult(result) {
if (result.IsSuccess) {
$('#loginPanel').hide;
$('#logoutPanel').show;
var username = $('#userName').val;
$('#username')
.html("<b>" + username + "</b>");
} else {
$('#message').text(result.ErrorString);
}
},
'json');
event.preventDefault;
})
});
</script>
Здесь
Для отправки данных мы используем функцию $.post, передав в нее предварительно сформированные данные, полученные с элементов управления. При вызове $.post мы определяем функцию OnResult, которая должна быть вызвана после завершения Ajax-запроса. Эта функция определяет обработку результата запроса и выводит либо сообщение об ошибке, либо приглашения для пользователя, в случае когда вход в систему был произведен удачно.
Полезные советы
В этой части главы мы рассмотрим несколько моментов, связанных с использванием технологии Ajax и библиотек jQuery и ASP.NET Ajax на практике.
Вопросы безопасности
Использование Ajax открывает новые возможности для разработчика и предлагает новый опыт для посетителя веб-ресурса. Но вместе с тем использование Ajax открывает новое поле действия для злоумышленников. Рассмотрим основные вопросы безопасности, которые следует иметь в виду при работе с запросами, в том числе и Ajax-запросами.
Обработка пользовательских данных
При работе с данными, полученными от пользователей, всегда необходимо соблюдать правила безопасности. Нужно относиться к любым таким данным как к потенциально опасным для отображения в разметке. Представим себе ситуацию, когда злоумышленник вместо того, чтобы ввести в поле своего логина какой-то текст, вводит туда опасный JavaScript-код. Тогда, если не принять никаких мер предосторожности, каждый из пользователей, который будет открывать страницу с выведенными данными злоумышленника на нашем сайте, потенциально будет уязвим. Предотвращение таких атак достигается путем декодирования опасного содержимого перед отображением на клиенте. В ASP.NET MVC существует метод расширения Html.Encode, который позволяет представить любой набор текстовых данных как безопасную последовательность символов и их HTML-представлений. Рассмотрим пример:
<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. Однако часто это очень неудобно для разработчика или вовсе невозможно. В таких случаях полезным будет следующее решение:
? для каждой пользовательской сессии формируется некая строка с уникальным значением;