不要对GET请求使用CSRF保护 . 要在GET请求中传递CSRF令牌,您必须将其放入URL本身(例如,在查询参数中),并且URL不是放置安全敏感信息的好地方 . 它们倾向于通过各种方式泄漏,尤其是在跟踪链接或从受保护页面获取资源时发送的 Referer 标头 .
您应确保所有具有活动效果的操作(即,更改数据库中的内容,写入文件系统或发送邮件的操作)仅通过POST请求公开,并使用CSRF令牌进行适当保护 . 没有任何有效效果的视图(例如查看页面,搜索某些内容)应该可以通过GET访问,并且不需要CSRF保护 . 然后,用户可以打开一个新选项卡并浏览到包含表单的页面而不会出现错误;表单将使用正确的参数生成,因此将提交确定 .
附带问题:您正在使用CSRF保护的Double Submit Cookie方法 . 这是......好吧......但不保护其他方法的一些场景 .
(具体来说,如果攻击者可以执行cookie固定攻击 - 例如通过利用邻居/子子域上的易受攻击的应用程序,或通过HTTP上的MitM攻击到HTTPS站点 - 他们可以通过让用户发送相同的内容来绕过CSRF保护它们在上一步中推送到用户的请求参数中的值 . )
如果该站点是敏感站点或由于附近其他不太受信任的应用程序而特别容易受到攻击,您可能希望考虑使用Synchronizer Token备选方案,或者Encrypted Token(也可以通过签名来完成;如果您不是使用任何类型的会话存储) .