Как защитить доступ к действиям MVC, которые возвращают JSON - PullRequest
3 голосов
/ 27 марта 2011

У меня есть общедоступный веб-сайт, который разработан с использованием ASP.NET MVC 3. Приложение MVC содержит контроллеры с действиями, которые возвращают JSON.Веб-страницы выполняют запросы AJAX против действий, которые возвращают JSON.

Несмотря на то, что данные, публикуемые с помощью действия JSON, не являются конфиденциальными, они являются собственностью, и меня беспокоит, что любой может вызвать действия, которые возвращают JSON, через междоменные вызовы или пользовательские приложения.Можно ли разрешить только веб-страницам приложения MVC доступ к действиям, которые возвращают JSON?Предоставляет ли ODATA какие-либо преимущества для решения этой проблемы?

Кто-нибудь знает ресурсы, которые описывают эту проблему как обязательство и как ее решить?

Ответы [ 5 ]

6 голосов
/ 27 марта 2011

Если ваше приложение общедоступно, то оно более сложное. Есть атрибут ValidateAntiForgeryToken, который может помочь против XSS и случайных запросов.

Если у вас есть защищенный паролем сайт, используйте атрибут Authorize.

OData имеет тот же набор проблем, что и сайт MVC.

1 голос
/ 28 марта 2011

Если вы используете роли, вы можете ограничить доступ с помощью атрибута Authorize.

0 голосов
/ 29 марта 2011

Вы можете использовать ValidateAntiForgeryToken, чтобы запретить людям делать запросы к вашим методам, однако, поскольку вы работаете с данными на стороне клиента, существует множество других способов доступа к вашим данным после их отправки клиенту. Вы можете сделать очень мало (если вообще что-нибудь), чтобы данные или информация, которую вы позволяете сделать общедоступной, не может быть каким-либо образом добыта

0 голосов
/ 28 марта 2011

Если вы действительно хотите обезопасить себя, вы можете обращаться с контроллерами, которые возвращают JSON, так же, как с базой данных и развертывать их в отдельном приложении, которое находится за брандмауэром, в то время как сервер переднего плана находится в ДЗ.

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

0 голосов
/ 28 марта 2011

У меня похожая настройка, но в моих устройствах iOS приходится общаться со страницами, которые отвечают в JSON.Я закончил тем, что создал ActionFilterAttribute, который проверяет, что устройство 1) добавлено в список разрешенных устройств по его UDId и 2), что пользователь, назначенный устройству, активен (в настоящее время используется).Проблема в том, что это вынуждает меня использовать POST-запросы, что для меня на самом деле не проблема, но для вас это может быть, так как вы можете разрешать GET-запросы.Я также могу ошибаться, я думаю, что механизм связывания по-прежнему будет анализировать объекты из GET-запроса, и фильтр, вероятно, все еще будет работать.fit:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
internal sealed class VerifyDeviceAttribute : ActionFilterAttribute {
    [Inject]
    public DeviceProvider DeviceProvider { private get; set; }

    public override void OnActionExecuting(
        ActionExecutingContext ActionExecutingContext) {
        string UDId = ActionExecutingContext.HttpContext.Request.Form["Authorization.UDId"];

        if (this.DeviceProvider.Exists(UDId) && !this.DeviceProvider.Get(UDId).User.Active) {
            ActionExecutingContext.Controller.ViewData.ModelState.AddModelError("User", "The user is not active");
        } else if (!this.DeviceProvider.Exists(UDId)) {
            ActionExecutingContext.Controller.ViewData.ModelState.AddModelError("UDId", "The UDId is empty");
        };
    }
}

Вы можете заметить, что я помещаю ошибки в контроллер ModelState, если они есть, и в результатах действий я всегда проверяю состояние модели перед форматированием ответа, поэтому убедитесь, чтоты всегда проверяешь свой ModelState!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...