使用MVC防止URL操作攻击?

3号是正确的做法。服务器端安全验证始终是您所需要的,因为这是您完全控制并可以依赖的机制。

第一个是模糊性的安全性,如果有人不小心在某个地方发布了他的URL(就像人们在复制/粘贴链接时经常使用会话ID一样),那么您的“安全性”就被破坏了。

数字2似乎是一个脆弱的安全-如果你经历了麻烦,最好实现适当的安全。这也允许人们在页面上加书签。

您不应该让您的URL成为“操作证明”,以保护底层功能。除此之外:大多数网站使URL更具可读性 http://stackoverflow.com/questions/741653/preventing-url-manipulation-attacks-with-mvc 例如,混淆可能是倒退的一步。

而是检查控制器中的权限,如果不允许用户编辑配置文件6,则引发异常。如果你不想到处都有“支票”,也许你可以把它们放进 ActionFilter 或者创建一些辅助方法,比如 CurrentUser.FindProfileToEditById(profileId) (如果不允许该操作,则引发异常)而不是 Profile.FindById(id) .

如果你想要一个没有“当前用户”的通用服务,你可以使用guid(比如涂鸦),但是这在各种方面都是一个安全威胁(facebook在他们的相册中有这个问题)。

我使用自定义授权过滤器来实现基于角色和所有者的访问控制。标准授权筛选器将允许您指定可以访问操作的命名角色或用户。我已经扩展了这个功能,允许您指定如果当前用户是数据的“所有者”,那么他们可能具有访问权限。我还有两个额外的过滤器,RoleRownerAuthorizationFilter和RoleRownerAssociatedAuthorizationFilter。首先检查可配置参数(通常 id )传入RouteData是“我的用户”表中当前用户的ID,或者如果当前用户处于任何列出的角色中。如果检查成功,则返回授权错误视图。

第二个允许我指定一个联接表,以及用于将RouteData中的参数与联接表中的一列关联的参数,以及当前用户与联接表中的另一列关联的参数。如果有一个条目同时匹配参数值和用户,那么我认为用户与数据相关,并且可以访问。如果您在指定的角色中,它还允许访问。在这三个不同的属性之间,我几乎满足了我所有的访问控制需求,这意味着我只需要用一个适当配置的属性来装饰就可以应用安全性。

用于访问站点的URL是来自客户端的数据,当涉及到安全性时,您应该始终将客户端提供的数据视为恶意数据。

不幸的是,没有解决这个问题的灵丹妙药。您需要在整个应用程序中实现访问限制。