前端生成CSRF token是否存在安全隐患？Django场景下相关技术问询

你提到的前端生成合法CSRF Token设置为Cookie使用的方案，除了无法设置HttpOnly标记之外，还存在以下几类明确的安全弊端：

• XSS攻击危害被大幅放大
  原生服务端生成的CSRF Token若设置HttpOnly标记，即使站点存在XSS漏洞，攻击者也无法直接读取Cookie中的Token值。而该方案下Token生成逻辑完全暴露在前端运行环境，且Cookie无HttpOnly保护，一旦出现XSS漏洞，攻击者既可以直接读取Cookie中的现有Token，也可以直接调用生成逻辑批量生成合法Token，完全绕过CSRF防护机制，危害程度远高于普通的CSRF Cookie缺失HttpOnly的场景。

• Token可预测风险显著提升
  绝大多数前端开发者自行实现的Token生成逻辑会使用非密码学安全的随机函数（比如JS原生Math.random()），攻击者只要拿到生成逻辑就可以批量预测合法Token。就算完全照搬Django原生的生成逻辑，前端运行环境没有服务端的高熵随机数池支撑，生成的Token随机度也远低于服务端生成的结果，存在被爆破预测的可能。

• 跨子域防护能力失效
  如果你的业务存在多个关联子域，前端生成的CSRF Cookie一旦配置了根域生效规则，任意一个子域的XSS漏洞都可以拿到根域下的CSRF Token，甚至直接在其他子域生成合法Token发起跨子域的伪造请求，原生服务端可实现的子域级Token绑定能力完全无法落地。

• 缺失会话绑定机制
  Django原生的CSRF Token默认和用户的服务端Session做关联校验，攻击者即使拿到某个用户的Token也无法在其他用户会话中使用。而前端生成的Token完全不和服务端会话绑定，攻击者只要诱导用户在站点执行任意注入脚本，就可以生成对应操作的合法Token，甚至可以提前批量生成Token构造恶意链接，诱导未登录用户点击后执行敏感操作。

• 合规风险
  网络安全等级保护以及多数金融、政务类行业的安全规范，明确要求敏感操作的校验凭证必须由服务端签发，前端自签Token的方案不符合这类合规要求，上线后会面临合规整改风险。

内容的提问来源于stack exchange，提问作者WTK