我在模型层验证了我的所有表单数据,但我还检查了我的表单是从哪里提交的(HTTP Referrer),我还发送了一个带有表单的令牌以帮助防止跨站点请求伪造,我的问题是这些检查应该在哪里完成? 在控制器还是模型层?
我正在考虑几种不同的方法来实现这一点,其中一种是在我的表单中使用某种受保护的方法AbstractController
来验证表单源和发布的令牌,但这可能会破坏 SRP。
我在模型层验证了我的所有表单数据,但我还检查了我的表单是从哪里提交的(HTTP Referrer),我还发送了一个带有表单的令牌以帮助防止跨站点请求伪造,我的问题是这些检查应该在哪里完成? 在控制器还是模型层?
我正在考虑几种不同的方法来实现这一点,其中一种是在我的表单中使用某种受保护的方法AbstractController
来验证表单源和发布的令牌,但这可能会破坏 SRP。
(..) 这些检查应该在哪里进行?在控制器还是模型层?
两者都不。
在我看来,CSRF 保护应该与其他形式的访问控制在同一级别处理:在 MVC 三元组之外。
如果应用程序无法验证令牌,则意味着Request
实例中的数据(或您的替代方案)不可信,因此需要将其废弃。我会在初始化和/的实例之前执行这样的检查。Controller
View
基本上,以不同的意图多次检查您的数据是明智的。我建议这些级别:
1) 前置控制器检查接收到的数据的完整性。如果您错过了一些令牌,或者从浏览器等处获得了一些超时,您会立即退出。您不会让这些请求到达您的 MVC。这是您可能需要suoshin的地方。原因是,更深层次的安全数据可能会与浏览器进行通信,即使出现错误也是如此。想象一下有人错过了安全令牌(攻击?),您的视图返回错误消息并设置了一些 cookie。使用这些,攻击者可能会在任何无效的表单请求后登录。
2) 前端控制器验证输入的内容是否可以从该用户等那里输入(例如,如果美国用户可能输入加拿大电话号码) 以“请输入正确的电话号码”的形式提供直接反馈“ 等等。
3) 模型验证数据是否处于可以安全保存和返回的状态,例如是否已转义、是否具有正确的长度等。