ASP.NET MVC 4.7开发场景下，将CSRF令牌值存储在DOM中是否安全？

你的直观判断是正确的：如果站点存在可被利用的XSS漏洞，存储在DOM中的CSRF令牌确实可以被攻击者直接读取窃取。但这里有两个非常容易混淆的设计边界，需要明确区分：
需要特别说明的是：不能因为XSS存在的场景下CSRF令牌可能被窃取，就否定CSRF防护的价值——CSRF防护的核心作用，是拦截没有页面JS执行权限的跨站伪造请求，比如通过诱导用户点击外链发起的接口调用，这类攻击场景下根本不存在XSS的执行环境，完善的CSRF校验完全可以把这类攻击拦在外面。

HttpOnly属性的设计目标 #

为Cookie设置HttpOnly的核心作用，是阻止JS脚本读取特定Cookie的内容，它的防护对象从来不是“防止CSRF令牌被XSS窃取”——这套防护逻辑是配合ASP.NET MVC AntiForgery机制的双令牌设计工作的：

• 机制本身会生成两个配对的令牌值：一个是存储在Cookie中的cookieToken，另一个是嵌入在页面DOM/表单中的formToken
• 只有当请求中同时携带和这两个值完全匹配的内容时，才会通过CSRF校验
  如果你给存cookieToken的Cookie设置了HttpOnly属性，攻击者就算通过XSS偷到了DOM里的formToken，因为读不到Cookie里对应的cookieToken，根本拼不出合法的完整令牌，依然没法伪造通过校验的请求。

DOM存储令牌的安全定位 #

把CSRF令牌通过meta标签存入DOM的实现方案，本身没有特殊的安全缺陷：

• 这套方案的设计前提，是CSRF防护的有效边界本来就不包含防御已经获得页面JS执行权限的XSS攻击
• 攻击者如果能在你的站点页面执行任意JS，根本不需要刻意“窃取CSRF令牌”：他可以直接以当前登录用户的权限，调用所有当前用户有权限访问的接口，读取页面上所有用户可见的敏感内容，这种场景下CSRF防护本来就已经完全失效了——因为XSS的危害等级远高于CSRF，一旦存在可利用的XSS漏洞，整个站点的安全防线都会被突破，纠结令牌存在DOM哪个位置没有实际意义。

结合你当前实现的优化建议 #

• 你现在写的TokenHeaderValue方法直接拼接完整的cookieToken:formToken字符串，反而扩大了不必要的暴露面：按照AntiForgery的原生设计，cookieToken应该通过后端响应写入HttpOnly Cookie，不应该通过JS可直接读取的接口返回完整的配对值，一旦这样做，所有存在于JS可访问环境的内容都会直接被XSS获取，攻击者不需要破解配对逻辑就能拿到完整的合法令牌。
• 选择meta标签存令牌和把令牌存在隐藏表单域、JS变量中的风险完全没有区别：只要是前端JS需要读取的内容，在存在XSS的场景下都会被窃取，不存在哪种存储方式更安全的差异。
• 真正缩小风险的核心动作，不是纠结令牌在DOM里的存储位置，而是从源头做好XSS防护，同时为存储cookieToken的Cookie配置HttpOnly、合适的SameSite属性，让单独窃取到的formToken无法通过校验。

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