Как я могу убедиться, что данные, отправленные в WebService с помощью jQuery AJAX, проходят через мой сайт, а не некоторые атаки

Мой код:

 function HandleSignUp() {
    var CurrentURL = document.URL;
    var obj, val;
    //ajax call started
    $.ajax({
        type: "POST",
        url: "../../webservice/GetAjaxDataWebService.asmx/RegisterNewUser",
        data: "{'UserFullName': '" + $('#SignUpName').val() + "','Email': '" + $('#SignUpEmail').val() + "','Password': '" + $('#SignUpPassword').val() + "'}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function (msg) {
            //msg.d contains the return value from web service call
            $.colorbox.close();

            val = eval(msg);
            obj = jQuery.parseJSON(val.d);

            UpdateLogin(obj.Email, obj.FirstName);

        }
    });
    //ajax call ended
}

Как я могу убедиться, что данные, отправленные в WebService с помощью jQuery AJAX, связаны с моим сайтом, а не с какой-либо атакой.

У меня есть аналогичный вызов ajax для Login, где я передаю идентификатор пользователя и пароль в веб-службу и аутентифицируюсь.

Есть ли способ иметь одноразовый токен запроса-ответа, чтобы удостовериться в его действительном вызове веб-службы.

Сообщите мне, если мой вопрос не ясен.

Ответ 1

Вы можете реализовать легкий механизм MAC-манипуляции, используя хэш-ключ (известный только вам)

  • Перед каждым вызовом веб-службы загрузите первые n байты полезной нагрузки вашего сообщения в хэш-ключ и вычислите хэш-значение.
  • Сделайте вызов в вашем веб-сервисе, отправив хэш-значение в заголовок http (я рекомендую заголовок авторизации, вы можете создать собственный заголовок Тхо.
  • В своем веб-сервисе перед выполнением любого запроса на обслуживание вы проверяете подлинность сообщения, вычисляя значение hash, используя те же данные, то есть первые N байтов, и сравнивайте их с хэш-значением в заголовке авторизации. Почитайте запрос, только если значение проверяется.

Здесь есть небольшая перегрузка, и предполагается, что передача происходит через защищенную строку, иначе сообщение все равно может быть захвачено. Но вы решаете проблему фиктивных вызовов.

Ответ 2

Сессии могут быть самым простым решением этой проблемы, в зависимости от вашей серверной инфраструктуры.

После успешного входа в систему откройте сеанс на сервере и установите значение; проверьте значение сеанса перед обработкой любого из ваших других API веб-сервисов.