能否通过Chrome控制台获取CSRF Token？及相关安全与实现疑问

1. 能不能用Chrome控制台拿到网站的CSRF Token？ #

当然可以。只要CSRF Token存在前端可访问的地方——比如页面里的隐藏输入框、普通Cookie、localStorage这些，你在Chrome控制台里写几行JS就能读出来。比如Token在<input name="csrf-token" type="hidden">里，直接用document.querySelector('input[name="csrf-token"]').value就能拿到；要是存在Cookie里，document.cookie或者CookieStore.get('csrf-token')也能获取。

2. CSRF Token能不能被脚本访问？是不是人类能看懂的格式？ #

• 脚本访问：得看存在哪儿。如果是存在DOM元素、localStorage、sessionStorage，或者非HttpOnly的Cookie里，同源的脚本完全能读；但如果是HttpOnly标记的Cookie，脚本就碰不到。
• 人类可读：绝大多数CSRF Token都是随机生成的字符串，是明文的文本格式，人能直接看懂，不是加密后的二进制内容。

3. 攻击者的恶意脚本能不能从合法用户浏览器里偷到CSRF Token，然后发起恶意请求？ #

这得分情况：

• 正常情况下，受浏览器同源策略限制，第三方网站的恶意脚本没法访问目标网站的DOM、Cookie、存储内容，所以拿不到Token；
• 但如果目标网站有XSS漏洞，攻击者就能把恶意脚本注入到目标网站页面里，这时候脚本和网站同源，就能轻松拿到Token，然后用这个Token发起合法格式的恶意请求。

4. 怎么防护CSRF攻击？ #

如果你要在系统里实现CSRF Token机制，结合下面这些方案能把安全性拉满：

• 合理存储和传递Token：
  • 把Token放在页面的隐藏表单字段里，提交表单或者发AJAX请求时一起带上；
  • 用户会话存在HttpOnly、Secure标记的Cookie里，不让脚本能拿到会话信息。
• 严格验证Token：
  • 后端必须核对请求里的Token和用户会话中存的Token是否一致，不一致就拒绝请求；
  • Token要随机生成，每个用户会话用独立的Token，别重复用。
• 利用浏览器的安全特性：
  • 给Cookie设置SameSite属性（选Strict或者Lax），限制Cookie只能在同站请求里发送；
  • 敏感操作别用GET方法，用POST或者PUT、DELETE，减少被轻易构造请求的可能。
• 堵上XSS漏洞：
  • 对用户输入的内容严格过滤、转义，别让恶意脚本注入进来；
  • 配置Content Security Policy（CSP），限制页面能加载和执行的脚本来源。

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