前端防范安全

随着互联网的发展，各种 Web 应用变得越来越复杂，满足了用户的各种需求的同时，各种网络安全问题也接踵而至。作为前端工程师的我们也逃不开这个问题

XSS

概念：cross-site-script 跨站脚本攻击，是一种注入代码攻击，攻击者在目标网站注入恶意代码，被攻击者登录网站时就会执行这个恶意代码，脚本可以读取本地的 cookie session 等用户敏感信息

分类：存储型（持久性），反射性（非持久性）， DOM

1. 存储型：恶意代码被存入了数据库中，

   解决方案：

   前端不信任用户输入，对于所有用户输入的进行转义/过滤传给服务器 前端不信任服务器的输入，对所有服务器传入的进行转义/过滤之后渲染到页面
   服务器不信任前端的输入，对所有前端传入的进行转义/过滤之后存到服务器

2. 非持久性/ DOM ：恶意代码被直接渲染到了页面，解决方案，对前端的输入进行转义/过滤之后渲染到页面

CSRF

概念：cross-site request forgery 跨站请求伪造，攻击者诱导受害者进入第三方网站，在第三方网站中，攻击者拿到了用户信息，绕过后台的限制，进行发送跨站请求。

解决方案：

1. 添加验证码(体验不好)

验证码能够防御 CSRF 攻击，但是我们不可能每一次交互都需要验证码，否则用户的体验会非常差，但是我们可以在转账，交易等操作时，增加验证码，确保我们的账户安全。

1. 判断请求的来源：检测 Referer (并不安全，Referer 可以被更改)

Referer 可以作为一种辅助手段，来判断请求的来源是否是安全的，但是鉴于 Referer 本身是可以被修改的，因为不能仅依赖于 Referer

1. 使用 Token(主流)

CSRF 攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个 CSRF 攻击者无法获取到的 Token。服务器通过校验请求是否携带正确的 Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

• 服务端给用户生成一个 token，加密后传递给用户
• 用户在提交请求时，需要携带这个 token
• 服务端验证 token 是否正确

1. Samesite Cookie 属性

为了从源头上解决这个问题，Google 起草了一份草案来改进 HTTP 协议，为 Set-Cookie 响应头新增 Samesite 属性，它用来标明这个 Cookie 是个“同站 Cookie”，同站 Cookie 只能作为第一方 Cookie，不能作为第三方 Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。

部署简单，并能有效防御 CSRF 攻击，但是存在兼容性问题。

Samesite=Strict

Samesite=Strict 被称为是严格模式,表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie，有能力阻止所有 CSRF 攻击。此时，我们在 B 站点下发起对 A 站点的任何请求，A 站点的 Cookie 都不会包含在 cookie 请求头中。

Samesite=Lax

Samesite=Lax 被称为是宽松模式，与 Strict 相比，放宽了限制，允许发送安全 HTTP 方法带上 Cookie，如 Get / OPTIONS 、HEAD 请求.

但是不安全 HTTP 方法，如： POST, PUT, DELETE 请求时，不能作为第三方链接的 Cookie 为了更好的防御 CSRF 攻击，我们可以组合使用以上防御手段。

csp是为了解决什么问题的?

CSP指的是内容安全策略，为了缓解很大一部分潜在的跨站脚本问题

CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。 CSP 提供了很多限制选项，涉及安全的各个方面： 资源加载限制 default-src：所有的外部资源，都只能从当前域名加载：Content-Security-Policy: default-src ‘self’ URL 限制 block-all-mixed-content：HTTPS 网页不得加载 HTTP 资源（浏览器已经默认开启） upgrade-insecure-requests：自动将网页上所有加载外部资源的 HTTP 链接换成 HTTPS 协议 plugin-types：限制可以使用的插件格式 sandbox：浏览器行为的限制，比如不能有弹出窗口等。