xss、csxf

• xss、csxf
• cookie和token都存放在header中，为什么不会劫持token

---

概念

• XSS
• Cross-site scripting 跨站脚本攻击
• 是一种安全漏洞，攻击者可以利用这些漏洞在网站上注入恶意的客户端代码。当受害者登录网站时就会自动运行这些恶意代码。
• CSRF
• Cross-site request forgery 跨站请求伪造
• 攻击者盗用了你的源身份，以你的名义发送恶意请求

原理流程

XSS

• 劫持 cookie 或者 localStorage，从而伪造用户身份相关信息

CSRF

• 流程
  • 1.用户 C 打开浏览器，访问受信任网站 A，输入用户名和密码请求登录网站 A
  • 2.在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 成功，可以正常发送请求到网站 A
  • 3.用户未退出网站 A 之前，在同一浏览器中，打开一个 TAB 页访问网站 B
  • 4.网站 B 接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点 A
  • 5.浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。

解决方案

XSS

• 劫持 cookie 或者 localStorage，从而伪造用户身份相关信息。
• 前端层面 token会存在哪儿？不外乎 cookie localStorage sessionStorage，这些东西都是通过 js 代码获取到的。
• 解决方案：过滤标签 <>，不信任用户输入， 对用户身份等 cookie 层面的信息进行 http-only 处理。如果您在 cookie 中设置了 HttpOnly 属性，那么通过 js 脚本将无法读取到 cookie 信息，这样能有效的防止 XSS 攻击

CSRF

• 是后端过于乐观的将header区的cookie取到（所以这才是主要原因，不是因为会自动携带 cookie 所以不安全，是后端代码不安全而已），并当作用户信息进行相关操作。
• 解决方案也很简单，对于 cookie 不信任，对每次请求都进行身份验证，比如 token 的处理。

cookie和token都存放在header中，为什么不会劫持token？

• 浏览器发送请求的时候不会自动带上token，而 cookie 在浏览器发送请求的时候会被自动带上。
• csrf 就是利用的这一特性，所以 token 可以防范 csrf，而 cookie 不能。