关于基于Local Storage与Cookie的CSRF防护方案的疑问

问题1：为何CSRF攻击者无法手动读取Cookie获取CSRF ID并添加至攻击请求中？ #

核心原因在于浏览器的同源策略：

• 攻击者的恶意页面和你的服务端属于不同域名，浏览器的安全规则会限制跨域JavaScript代码读取非同源域名下的Cookie内容。
• 要是你的JWT Cookie还设置了HttpOnly属性（生产环境最佳实践），哪怕是同域的恶意脚本（比如XSS注入的代码）也没法通过JS读取这个Cookie，安全层级更高。
• CSRF攻击的核心是蹭浏览器自动携带Cookie的特性，但攻击者没办法自主获取或修改目标域的Cookie内容——跨域请求里要加自定义请求头必须用JS，但JS拿不到Cookie里的CSRF ID，自然没法把ID塞进请求头里。

问题2：使用Local Storage存储该ID是否会面临XSS+CSRF组合攻击的风险？ #

答案是肯定的，不过本质是XSS漏洞本身带来的威胁：

• 如果你的站点存在XSS漏洞，攻击者注入的恶意脚本可以直接读取Local Storage里的CSRF ID（Local Storage没有类似Cookie的HttpOnly限制，同域脚本都能访问）。
• 拿到ID后，恶意脚本可以在用户浏览器里发起同源请求：浏览器会自动带上Cookie里的JWT（包含CSRF ID），脚本同时把从Local Storage拿到的ID放到请求头里——服务端校验时会认为两者匹配，直接通过验证。
• 其实更直白地说，XSS漏洞本身就已经能绕过几乎所有CSRF防护，因为攻击者可以直接以用户身份执行任意同域操作，根本不需要依赖CSRF的跨域请求逻辑。

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