在使用EF检索和提交对SQL的更改之前检查UserId是否足够安全

Question

我正在努力确保用户不能访问或修改表中属于其他用户的行。经过一些研究，这就是我提出的方法(示例代码)

public virtual ActionResult Edit(int id)
{
var myEntity = myEntityService.GetEntity(id);
if (myEntity == null)
return HttpNotFound();
if (myEntity.UserId != User.Identity.GetUserId())
return HttpNotFound();
MyEntityFormModel editMyEntity = Mapper.Map<MyEntity, MyEntityFormModel>(myEntity);
return View(editMyEntity);
}
}

其他CRUD操作也有类似的方法：根据实体的Id检索实体，然后检查以确保实体的UserId属性(从AspNet.Identity.GetUserId()检索并在创建过程中存储)与用户UserId匹配，然后才允许进行任何CRUD操作。

这足够安全吗？这是阻止人们访问彼此数据的有效方法吗？还是我应该实施另一种安全检查？

Answer 1

我还没有与EF合作了解该框架中可能的细节，但这是我在nHibernate中要做的。

对于GetEntity，在查询参数中同时执行get-by-Id和UserId。它节省了sql服务器负载、带宽和网络使用，因为如果实体对登录用户无效，则不会返回任何不必要的数据。

插入：这不会是一个问题，因为你需要设置实体。UserId为已登录的用户Id。

更新：这是您可能需要手动验证实体是否存在的地方。UserId与已登录用户的Id匹配。但请检查EF是否有方法执行"更新实体，其中Id=X和UserId=Y"-从长远来看，这将使其更加安全和易于维护。

Delete：与GetEntity相同-通过Id和UserId作为查询参数进行删除。因此，如果该记录不是为当前用户创建的，则不会删除任何内容。

我想，一般的方法几乎就像对待实体一样，就好像它们在Id和UserId上有一个复合键。

所以MyEntityDbContext看起来像这个

interface IMyEntityDbContext {
Entity GetEntity(int id, int userId);
int Insert(Entity entity);
void Delete(int id, int userId);
void Update(Entity entity);
//or if possible in EF
void Update(Entity entity, int userId);
}

它减少了只需要在Update语句中写入的验证逻辑的数量。它还使获取或删除不同用户的记录成为绝对不可能。