如何保护对返回 JSON 的 MVC 操作的访问

发布于 2024-10-27 05:53:33 字数 262 浏览 6 评论 0原文

我有一个使用 ASP.NET MVC 3 开发的面向公众的网站。MVC 应用程序包含带有返回 JSON 的操作的控制器。网页针对返回 JSON 的操作执行 AJAX 请求。

尽管通过 JSON 操作发布的数据并不敏感,但它是专有的,而且我担心任何人都可以通过跨域调用或自定义应用程序来调用返回 JSON 的操作。有没有办法只允许我的 MVC 应用程序网页访问返回 JSON 的操作? ODATA 是否为解决此问题提供了任何好处?

有谁知道将此问题描述为责任的资源以及如何解决它?

I have a public facing website that is developed with ASP.NET MVC 3. The MVC application contains controllers with actions that return JSON. The web pages execute AJAX requests against the actions that return JSON.

Even though the data that is published with the JSON action is not sensitive, it is proprietary, and I’m concerned that anybody can call the actions that return JSON through cross domain calls or custom applications. Is there a way to only allow my MVC application webpages access to the actions that return JSON? Does ODATA provide any benefits for solving this problem?

Does anyone know of resources that describes this issue as a liability and how to solve it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

一杆小烟枪 2024-11-03 05:53:33

如果您的应用程序是公开的,那么它会更加棘手。 ValidateAntiForgeryToken 属性可以帮助抵御 XSS 和随机请求。

如果您有受密码保护的站点,请使用Authorize 属性。

OData 与 MVC 站点存在同样的问题。

If your application is public, then its more tricky. There's the ValidateAntiForgeryToken attribute which can help against XSS and random requests.

If you have a password protected site, use the Authorize attribute.

OData has the same set of problems the MVC site would have.

所有深爱都是秘密 2024-11-03 05:53:33

如果您使用角色,您可以使用授权属性限制访问。

If you are using Roles, You can restrict access using Authorize attribute.

静谧幽蓝 2024-11-03 05:53:33

我有类似的设置,但在我的设备中,iOS 设备必须与以 JSON 响应的页面进行通信。我最终创建了一个 ActionFilterAttribute 来验证设备是否 1) 通过其 UDId 添加到允许的设备列表中,以及 2) 分配给该设备的用户是否处于活动状态(当前正在使用)。问题是这迫使我发出 POST 请求,这对我来说确实不是问题,但对你来说可能是问题,因为你可能允许 GET 请求。我也可能是错的,我认为模型绑定器仍然会解析 GET 请求中的对象,并且过滤器可能仍然会工作。

无论如何,这是我的过滤器的代码,您认为合适的修改器:

[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

I have a similar setup, but in mine iOS devices have to communicate with the pages that respond in JSON. I ended up creating an ActionFilterAttribute that verifies that the device is 1) added to the list of allowed devices by its UDId and 2) that the user assigned to the device is active (currently employed). The problem is that this forces me into POST requests, which to me it really isn't a problem, but to you it may be since you may be allowing GET requests. I also could be wrong, I think the model binder will still parse the objects from a GET request and the filter will probably still work.

Anyway, here's the code to my filter as it is, modifier as you see 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");
        };
    }
}

You may notice that I'm pushing errors into the controller ModelState, if there's any, and in the action results I always check the model state before formatting the response, so make sure you're always checking your ModelState!

自我难过 2024-11-03 05:53:33

如果您确实想确保安全,您可以像对待数据库一样对待返回 JSON 的控制器,并将它们部署到位于防火墙后面的单独应用程序,而前端边缘服务器位于 DMZ 中。

客户端可以连接到前端 Web 服务器,而前端 Web 服务器又调用防火墙后面的 JSON 资源。客户端无法直接连接到 JSON 资源。

If you really want to get secure, you could treat the controllers that return JSON the same way you'd treat your database and deploy them to a separate app that sits behind the firewall, whilst the front end edge server sits in the DMZ.

The clients can connect to the front end web server which in turn calls the JSON resources behind the firewall. The client can't directly connect to the JSON resources.

冷心人i 2024-11-03 05:53:33

您可以使用 ValidateAntiForgeryToken 来防止人们向您的方法发出请求,但是由于您正在使用数据客户端,因此在数据发送到客户端后,他们可以通过多种其他方式访问您的数据。您几乎无法采取任何措施(如果有的话)来防止您允许公开访问的数据或信息以某种方式被挖掘

You can use the ValidateAntiForgeryToken to prevent people from making requests to your methods however since you are working with the data client-side there are a plethora of other ways for them to access your data once it is sent to the client. There is very little (if anything) you can do to prevent data or information you allow to be publicly accessible form being mined in some fashion

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文