在哪里验证 MVC 应用程序中的表单引用者和令牌？答案

【问题标题】：Where to validate a forms referrer and token in a MVC application?在哪里验证 MVC 应用程序中的表单引用者和令牌？
【发布时间】：2013-05-31 04:54:59
【问题描述】：

我在模型层验证了我的所有表单数据，但我还检查了我的表单是从哪里提交的（HTTP Referrer），我还发送了一个带有表单的令牌以帮助防止跨站点请求伪造，我的问题是这些应该在哪里做检查？在控制器还是在模型层？

我想了几种不同的方法来实现这一点，其中一种是在我的 AbstractController 中使用某种受保护的方法来验证表单源和发布的令牌，但这可能会破坏 SRP。

【问题讨论】：

我投票给控制器...该模型不应该绑定到它正在使用的环境。如果您将检查塞入模型中，那么您将如何使用模型说一个 cron 任务。
Referrer 检查几乎完全是浪费时间。您要么允许空引用者并让自己易受攻击，要么禁止它们并为合法用户破坏您的应用程序。同步器令牌是击败 CSRF 的有效措施；推荐人检查不是。

标签： php security model-view-controller

【解决方案1】：

(..) 这些检查应该在哪里进行？在控制器还是在模型层？

都没有。

在我看来，CSRF 保护应该与其他形式的访问控制在同一级别处理：在 MVC 三元组之外。

如果应用程序无法验证令牌，则意味着Request 实例（或您的替代品）中的数据不可信，因此需要废弃。我会在Controller 和/的View 实例初始化之前执行此类检查。

【讨论】：

确切地说，CSRF 令牌没有验证某些用户执行某些操作的权限。它正在验证应用程序本身的通信完整性，应该这样对待。

【解决方案2】：

基本上，以不同的意图多次检查您的数据是明智的。我建议这些级别：

1) 前置控制器检查收到的数据的完整性。如果您错过了一些令牌，或者从浏览器等处获得了一些超时，您会立即退出。您不会让这些请求到达您的 MVC。这里是您可能需要 suoshin 的地方。 原因是，即使出现错误，更深层次也可能与浏览器通信安全数据。想象一下有人错过了安全令牌（攻击？），您的视图返回错误消息并设置了一些 cookie。使用这些，攻击者可能会在任何无效的表单请求后登录。

2) 前端控制器验证输入的内容是否可以从该用户等的表格中输入（例如，如果美国用户可能输入加拿大电话号码）提供直接反馈是必要的以“请输入正确的电话号码”等形式。

3) 模型验证数据是否处于可以安全保存和返回的状态，例如如果它已被转义，则具有正确的长度等。

【讨论】：