细读 JS | XSS、CSRF 浅谈

配图源自 Freepik

一、前提

Cookie 常用于会话状态管理、个性化设置等。
在浏览器可以通过 document.cookie 来访问 Cookie
document.cookie 只能获取当前作用域下的 Cookie，这个作用域受 Domain 和 Path 共同影响。

二、CSRF 攻击

它与 Cookie 相关

1. 什么是 CSRF？

CSRF 是 Cross-Site Request Forgery 的简称，译为“跨站请求伪造”。

我们知道，假设有两个网站 A 和 B：

只要在 B 网站发起了 A 网站的 HTTP(S) 请求，这个就算是跨站请求（至于算不算攻击就另说）。

当你访问并登录网站 A，服务器返回了一些 Set-Cookie 字段。若前往 B 网站，并在 B 网站发起了 A 网站的请求，这时候在 HTTP 请求头是会自动带上 A 网站的 Cookie 的（这里假定没有 Cookie 的 SameSite 限制）。

关于第二点，可能会有人疑惑。

先明确一下，通过 JS 脚本（document.cookie）只能获取本站下的 Cookie，换句话说，在 B 网站里只能获取 B 网站的 Cookie，是永远没有办法获取到网站 A 的 Cookie 的。这是脚本的行为。

其次，在发起 HTTP 请求时，会有一种自动携带 Cookie 的行为。它会自动带上所请求 URL 对应站点的相关 Cookie。

CSRF 攻击只是利用了 HTTP 请求自动携带 Cookie 的特性进行攻击，攻击者还是无法获取到被攻击网站的 Cookie 的。这与 XSS 不同，它是直接拿到被攻击网站的 Cookie，然后进行攻击。

2. 如何应当 CSRF？

方案一：放弃 Cookie，使用 Token

既然 CSRF 是利用了 HTTP 请求自动携带 Cookie 的特性，伪造请求以达到欺骗服务器的目的。那么只要我们不使用 Cookie 的方式来验证用户身份，转用 Token 策略，就能完全避免 CSRF 攻击。

方案二：SameSite

这是 Chrome 51 引入的新特性，它有三个值：None、Lax、Strict。自 Chrome 80 起，Cookie 的 SameSite 默认值为 Lax（在不设置 SameSite 时，其默认值取决于浏览器的默认值）。亦可主动设置为 None，但与此同时，Cookie 必须设置为 Secure。

这个特性可以解决 CSRF 攻击的问题，表示当前页面与请求的 URL 是相同的，才会携带上这个 Cookie。

还是前面的例子，攻击者 B 网站与被攻击者 A 网站是不同域的，当在 B 网站内发起 A 网站的请求时，对应 Cookie 就不会携带上。

但 SameSite 较新，在兼容性上可能不太好。

方案三：服务端 Referer 验证

在发起 HTTP 请求时，在请求头中会有 Referer 字段，它表示当前域的域名。服务端可以通过这个字段来判断请求是否来自“真正”的用户请求。

但是 Referer 是可以伪造的，因此并不可靠。

虽然 Referer 并不可靠，但用来防止图片盗链还是足够的，毕竟不是每个人都会修改客户端的配置。（一般只允许站内访问）

需要注意的是，Referer 的正确英语拼法是 referrer。由于早期 HTTP 规范的拼写错误，为保持向下兼容就将错就错了。例如 DOM Level 2、Referrer Policy 等其他网络技术的规范曾试图修正此问题，使用正确拼法，导致目前拼法并不统一。

三、XSS 攻击

XSS，是 Cross-Site Scripting 的简称，译为“跨站脚本攻击”。命名应该是为了与 CSS 进行区分。

1. 什么是 XSS？

XSS 是由于不安全的数据引起的，可能是提交表单数据，有可能是页面路径的参数问题。

与 CSRF 不同的是，CSRF 是利用了 HTTP 自动携带 Cookie 的特性来达到攻击的目的，攻击者无法通过 JS 脚本获取到被攻击者的 Cookie 等信息的。而 XSS 则是利用一些不安全的数据，例如是一个 <script> 标签，然后获取到用户的一些信息，对其发起攻击。

未完待续...

References

彻底理解 Cookie 以及 Cookie 安全

toFrankie / blog