ASP.NET PageMethods и JQuery AJAX Post - Насколько это действительно безопасно? - PullRequest
Новая
       15

ASP.NET PageMethods и JQuery AJAX Post - Насколько это действительно безопасно?

4 голосов
/ 01 мая 2009

У меня есть следующий сценарий - и что я действительно ищу, так это реальную помощь от реальных людей. Предложения / Решения? Пожалуйста.

У меня есть экстранет-сайт для бывших. www.foo.com (asp.net 3.5) Я использую JQuery 1.3.2 для вызова PageMethods ValidateLogin на странице default.aspx (www.foo.com/default.aspx)

Код будет выглядеть так 

$.ajax({
            type: "POST",
            contentType: "application/json; charset=utf-8",
            dataType: "json",
            url: "Default.aspx/ValidateLogin",
            data: '{' + arg + '}',
            success: function(data) {
                if (data.d != 0) {
                    window.location = "http://www.google.com";
                } else {
                    alert("Invalid UserName/Password.");
                    ResetLoginForm();
                }
            },
            error: function(xhr, status, error) {
                var strerror = xhr.status + error;
                alert("Error Communicating with Server:" + strerror);
                ResetLoginForm();
            }
        });

Код сохраняется во внешнем js-файле. Для ex default.js.

Поскольку этот сайт является общедоступным, любой может загрузить файл default.js и, таким образом, взглянуть на приведенный выше код.

У меня вопрос, как только человек получит этот URL: «Default.aspx / ValidateLogin», он может сделать запрос к серверу, и сервер с гордостью ответит на запрос.

Какие у меня есть варианты? как проверить запрос? Как предотвратить подобные несанкционированные запросы?

Ответы [ 4 ]

4 голосов
/ 02 мая 2009

Веб-запросы по своей природе общедоступны. Им даже не нужно смотреть на исходный файл. Они могут просто отслеживать HTTP-запросы и воспроизводить их (это очень просто с помощью такого инструмента, как, например, fiddler).

Проблема с дросселированием

Дросселирующие решения действительно нежизнеспособны, хотя они снижают частоту атак. Проблема в том, что злоумышленник может написать сценарий, который выполняется в течение нескольких дней. Опять же, он может использовать прокси для отправки параллельных запросов. И если вы дросселируете для каждого имени пользователя, то противник может достичь DoS, пытаясь ввести ложный вход в систему на законных именах пользователей, и когда фактический пользователь пытается войти, он не будет знать, почему он заблокирован.

Решение

Типичный подход заключается в использовании одноразовых ключей. Это потребует некоторой дополнительной работы, но это уменьшит проблему, и это рекомендуется, только если вы действительно ожидаете нападения или что-то в этом роде. Упрощенная версия этого позволит клиенту передавать одноразовый ключ в качестве параметра запроса URI. Ключ выдается сервером клиенту в первую очередь. Как только запрос сделан, сервер проверяет, существует ли одноразовый ключ в базе данных, и разрешает запросы. Он немедленно удаляет одноразовый ключ, поэтому пользователь не может сделать еще один запрос с тем же одноразовым ключом, но тогда серверу потребуется выдать больше одноразовых ключей пользователю.

Упрощенное решение состоит в том, чтобы разрешать только аутентифицированным пользователям отправлять запросы веб-служб, но поскольку вы разрабатываете систему входа в систему, это, очевидно, не прилипает.

Я бы об этом не беспокоился, если бы у тебя не было противных противников.

1 голос
/ 02 мая 2009

Я предполагаю, что вы показали, что ваш метод Page загружает сеанс, поэтому я думаю, что вы можете установить переменную сеанса при загрузке страницы и затем проверить, существует ли она при вызове метода страницы. Это не самая безопасная вещь в мире, но это поможет.

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

0 голосов
/ 01 мая 2009

Вы также можете поставить капчу после, скажем, 2-3 неудачных попыток входа в систему, что позволит избежать перебора.

0 голосов
/ 01 мая 2009

Я бы сказал, что нет проблем; Тем не менее, вы, вероятно, захотите сделать какое-нибудь ограничение скорости , чтобы люди не могли попробовать грубое принуждение.

...