【问题标题】:How to prevent users from forging form data如何防止用户伪造表单数据
【发布时间】:2015-10-30 00:13:45
【问题描述】:

我正在开发一个 C# MVC 应用程序,其中用户将应用程序提交给管理用户进行审查。管理用户可以批准或拒绝应用程序。我的管理员主页呈现提交的申请列表,点击每个申请会打开一个处理申请的新页面。

我的担心很简单:由于每个应用程序的“Id”属性是管理“处理应用程序”表单上的隐藏 html 元素,因此用户可能会修改应用程序 ID 并提交表单(反过来批准/拒绝不适当的申请)。我可以通过对“AppId”使用 Session 对象并验证表单发布的 AppId 与会话 AppId 相同来解决此问题。

但是(这是真正的问题),如果我设置 Session["AppId"] = applicationId,如果用户想在提交第一个应用程序之前尝试处理另一个应用程序,那么该会话对象很容易被覆盖。也许管理员用户认为自己是一个多任务处理者并打开两个“处理应用程序”窗口。本质上,第一个 Session["AppId"] 将被第二个覆盖。这会导致回发出现问题,因为现在我无法根据 Session 验证任何内容。

在写这篇文章时,我意识到我可以添加控件来防止用户同时处理多个应用程序。虽然有替代方法吗?同样值得注意的是,只有管理员用户才能伪造应用程序 ID,这不太可能,因为 Web-App 旨在帮助管理员用户。实际上,我只是在为这些场景寻找最佳实践,而不是担心有人会在我的表单上伪造元素。

我最好的方法是在会话中实际存储一个 AppId,并防止管理员一次处理多个应用程序(这样会话对象就不会被覆盖)?看起来是这样,但我喜欢社区的建议。

PS:我意识到这个问题类似于Secure way to stop users from forging forms。但是,我认为最大的不同是我目前允许用户一次处理多个应用程序,这使我无法将单个会话对象用于“AppId”。

【问题讨论】:

  • 不向用户传递秘密?为什么不在 URL 中或作为 cookie 向用户传递他们会话的唯一标识符,并将所有数据安全地保存在服务器上?这样他们就没有什么可以编辑/破坏/破解的了。

标签: c# model-view-controller session-variables


【解决方案1】:

我会从“健全和安全”的角度来处理这个问题。用户应该只能更改他们应该更改的内容,数据应该 [也] 在服务器端进行验证,然后您可以忽略所有伪造 :-)

【讨论】:

  • 我同意。我决定在页面加载时检查我的会话对象,以确保 AppId 尚未在会话中。如果会话中有 AppId,我将重定向用户以使用适当的警告消息处理该应用程序。基本上,一次只能处理一个应用程序,以防止伪造表单元素。
  • 不必要的限制和并发症。检查他们是否应该编辑 ID,验证输入,然后允许它。不需要缓存任何东西,如果用户只能通过使用 UI 来伪造编辑,他们为什么要伪造任何东西?你为什么要关心它是否是伪造的,如果他们有权编辑它,数据是否正确?
  • 但是用户应该不能通过 UI 编辑 App ID。我只需要它保留在表单上,​​这样我就知道在回发时要编辑哪个应用程序。使用 session 似乎可以缓解这种情况。
  • "你为什么要关心它是否是伪造的,如果他们有权编辑它,数据是否正确?"用户有权编辑除应用程序 ID 之外的所有内容,因为编辑会导致编辑影响不同的应用程序。
  • 我假设 appid 是主键,所以如果他们伪造它,他们就会编辑另一条记录。如果不是主键,则不需要缓存...
【解决方案2】:

我发现的最佳方法是在页面加载时检查 AppId 会话对象。如果存在,则用户没有完成对原始应用程序的处理(该场景可以通过多种方式处理。我会让您决定什么是最好的,但您可能会将用户重定向回以使用适当的方式处理原始应用程序警告信息解释发生了什么)。这是我能想到的防止使用单个会话对象在表单上伪造 AppId 的唯一方法。

【讨论】:

  • 经过进一步考虑,我认为@Miloslav Raus 的观点很好。我担心的是管理员用户恶意伪造数据,但管理员有能力直接编辑任何可能被伪造的记录。有人只是为了搞砸而想搞砸数据,这会成为我项目中的一个问题。
  • 我同意他的方法可能更合适。我只是想用简单的解决方案来回答“如何防止用户伪造表单数据”这个问题:存储您在会话中引用的数据的 ID,并且一次只允许用户编辑一个表单。
  • 会话、数据库、键值对存储(即服务器端)。或在客户端对要保护的数据进行签名/加密。但是对于允许用户正常进行的更改,没有任何保护措施。
猜你喜欢
  • 1970-01-01
  • 2015-08-21
  • 1970-01-01
  • 2014-10-15
  • 2012-01-21
  • 1970-01-01
  • 1970-01-01
  • 2017-01-09
  • 1970-01-01
相关资源
最近更新 更多