前端安全
XSS
什么是 XSS
- Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全
XSS 分类
存储型 XSS
攻击者将恶意代码提交到目标网站的数据库中。
用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。反射型 XSS
攻击者构造出特殊的 URL，其中包含恶意代码。
用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。DOM 型 XSS
攻击者构造出特殊的 URL，其中包含恶意代码。
用户打开带有恶意代码的 URL。
用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
XSS 防范措施
Content Security Policy
禁止加载外域代码，防止复杂的攻击逻辑
禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）
禁止未授权的脚本执行（新特性，Google Map 移动版在使用）
合理使用上报可以及时发现 XSS，利于尽快修复问题输入内容长度控制
对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度
其他安全措施
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
验证码：防止脚本冒充用户提交危险操作。
CSRF 攻击
什么是 CSRF
- CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的
典型过程
受害者登录 a.com，并保留了登录凭证（Cookie）
攻击者引诱受害者访问了 b.com
b.com 向 a.com 发送了一个请求：a.com/act=xx 浏览器会默认携带 a.com 的 Cookie
a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
a.com 以受害者的名义执行了 act=xx
攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作
CSRF 的特点
攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”
跨站请求可以用各种方式：图片 URL、超链接、CORS、Form 提交等等部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪
CSRF 防护策略
根据 CSRF 的两个特点：
CSRF（通常）发生在第三方域名。
CSRF 攻击者不能获取到 Cookie 等信息，只是使用。针对这两点，我们可以专门制定防护策略，如下：
阻止不明外域的访问
同源检测
Samesite Cookie提交时要求附加本域才能获取的信息
CSRF Token
双重 Cookie 验证
CSRF 防护-同源检测
- 使用 Origin Header 确定来源域名
- 使用 Referer Header 确定来源域名
设置 Referrer Policy 的方法有三种：
在 CSP 设置
页面头部增加 meta 标签
a 标签增加 referrerpolicy 属性
CSRF 防护-Token
- CSRF Token 的防护策略分为三个步骤
- 将 CSRF Token 输出到页面中
- 页面提交的请求携带这个 Token
- 服务器验证 Token 是否正确
CSRF 防护-双重 Cookie 验证
- 双重 Cookie 采用以下流程：
- 在用户访问网站页面时，向请求域名注入一个 Cookie，内容为随机字符串（例如 csrfcookie=v8g9e4ksfhw）。
- 在前端向后端发起请求时，取出 Cookie，并添加到 URL 的参数中（接上例 POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
- 后端接口验证 Cookie 中的字段与 URL 参数中的字段是否一致，不一致则拒绝。
CSRF 防护-Samesite Cookie 属性
从源头上解决这个问题，Google 起草了一份草案来改进 HTTP 协议，那就是为 Set-Cookie 响应头新增 Samesite 属性，它用来标明这个 Cookie 是个“同站 Cookie”，同站 Cookie 只能作为第一方 Cookie，不能作为第三方 Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax
Samesite=Strict
这种称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外
Samesite=Lax
这种称为宽松模式，比 Strict 放宽了点限制：假如这个请求是这种请求（改变了当前页面或者打开了新页面）且同时是个 GET 请求，则这个 Cookie 可以作为第三方 Cookie