【问题标题】:Preventing unintended CRUD actions in mvc防止 mvc 中的意外 CRUD 操作
【发布时间】:2019-12-22 05:42:00
【问题描述】:

就我所知道的提供一些背景信息。我前段时间从这个tutorial 中了解到,即使您在查看使用fiddler 之类的工具更改POST 数据和更改值是多么容易。

在这种情况下你要做的是使用模型绑定来指定你想要编辑的字段列表并忽略其余的

[HttpPost]
[ActionName("Edit")]
public ActionResult Edit_Post(int id)
{
    EmployeeBusinessLayer employeeBusinessLayer = new EmployeeBusinessLayer();

    Employee employee = employeeBusinessLayer.Employees.Single(x => x.ID == id);
    UpdateModel(employee, new string[] { "ID", "Gender", "City", "DateOfBirth" });
                                             ^^^ Name isnt updated
    if (ModelState.IsValid)
    {
        employeeBusinessLayer.SaveEmployee(employee);

        return RedirectToAction("Index");
    }

    return View(employee);
}

现在我了解了使用 AspNet.Identity 的身份验证。

  • 可以检查用户是否未通过身份验证以将其发送到登录页面。
  • 如果用户属于某个Role,我可以显示个性化菜单。
  • 或者检查用户的联系人列表并只显示那些。

但即使您在创建视图之前根据user_id 过滤联系人列表,您也可以使用此类链接访问操作EDITDELETE

  http://MVCDemo/Employee/Edit/1
  http://MVCDemo/Employee/Delete/1

而且只要你通过了身份验证,你就可以更改其他用户的数据。

那么,如何将身份验证与 CRUD 操作集成以避免意外操作?

在我看来,要解决这种情况,我必须应用类似于模型绑定示例的东西。 get 和EditDelete post 请求时,首先使用id 从DB 中获取Employee 并比较是否属于当前用户。

但这会在所有函数中创建大量重复代码。

那么处理这个问题的正确方法是什么?

编辑

尽量说清楚。假设我有一个地址簿应用程序。每个用户都有联系人:

 contact_id    user_id     name    phone ....
      1          1          A
      2          1          B
      3          1          C
      4          2          D
      5          2          E
      6          2          F

显示联系人的操作使用经过身份验证的user_id 过滤联系人,然后将其发送到视图。

然后您有一个编辑/删除操作,您可以在其中获得contact_id 并处理更新/删除。即使两个用户都有权执行这些操作,他们也不应该影响其他用户的联系人。但正如我所解释的,使用 fiddler 之类的工具非常容易更改页面。

【问题讨论】:

    标签: c# asp.net-mvc authentication roles


    【解决方案1】:

    我只能根据个人经验发言,但我不知道任何 MVC 功能可以为您管理这个;我只采取过您概述的从数据库中检索数据模型并显式编写逻辑以检查当前用户是否有权修改此资源的方法,如果没有则返回 401 错误。

    【讨论】:

    • 问题未授权。 UserA 可以编辑EmployessAUserB 只能编辑EmployessB
    • 啊,我明白了,我的错。
    【解决方案2】:

    您可以将传入请求的用户 ID 与您在会话中拥有的用户 ID、加密的 cookie 或您使用的 jwt 等 Web 令牌进行比较。

    通常,如果我有负载均衡器,我会使用加密的 cookie,在其中存储登录用户的 id,并将其与我从请求中获得的 id 进行比较。如果两者都匹配,则更新/删除配置文件,否则返回 Unauthorized。

    在 Session 或令牌的情况下也可以这样做。

    【讨论】:

    • 但在这种情况下,user_id 是相同的,问题是您可以更改帖子数据并使用与该user_id 无关的不同employee_id。假设您有一个联系人列表。您可以删除自己的联系人,但不能删除其他用户的联系人。
    • 由于 user_id 将被加密,其他用户不能冒充其他用户。您需要将联系人列表与有权访问它的 user_id 进行映射。如果用户正在干预帖子数据,他只能针对他自己的联系人这样做,因为您将检查用户是否映射到该联系人,如果是,则将其删除,否则返回未授权
    猜你喜欢
    • 1970-01-01
    • 2014-07-09
    • 1970-01-01
    • 2015-03-28
    • 2018-12-09
    • 2016-12-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多