浏览本文大略须要 5 分钟。
今晚想写这篇文章是有起因的，其实之前老陈也理解过前端的一些平安，然而理解得不够粗浅吧，导致最近一次小面试错漏百出，所以接着这个机会，补一补本人的前端平安的常识。
一、XSS 是个啥玩意
明天咱们理解一下什么是 XSS，俗称跨站脚本攻打，也就是你的页面有一些破绽，能够让攻击者注入代码，达到窃取信息的目标。
例如：可能获取页面的 dom,cookie,localStorage, 发送申请等等。
二、XSS 的类型
这里过后在面试的时候一顿乱说，感觉还是能够整顿一下，尽管有一些说的有点谬误。
第一种就是反射类型，能够通过 URL 注入参数，注入之后，咱们能够获取到以后页面的一些要害信息，这种反射类型的注入，不是持久性的。
第二种就是存储型注入，存储到数据库后读取注入。
第三种就是基于 DOM，被执行的歹意脚本会批改页面脚本构造。
三、XSS 的注入点
那么咱们能够去 XSS 注入的点哪里呢？第一个是 HTML 的节点内容或者属性，第二个是 Javascript 代码，第三个富文本。
咱们能够探讨一下，对于一些进攻的伎俩。
如何避免反射性的 XSS，能够通过浏览器的进攻，只能进攻注入到 HTML 的节点内容或者属性的 XSS。
那么咱们在一些字符串模板应用的过程中，可能会输出 <script></script> 这种就会存在被浏览器执行的危险，所以咱们须要将字符串 < 和 > 本义为 < 和 >。
而后就是须要进攻 HTML 属性。
<template>
<img :src="image" />
</template>
<script>
image = 'www.qq.com/a.png" onload="alert(1)'
</script>
// 以上是伪代码
// 输入后果
<img src="www.qq.com/a.png" onload="alert(1)">从输入后果咱们就能看到，这样的注入形式，会导致执行 onload 的事件，非常危险，所以咱们也是通过本义的形式来解决，先本义“，同时本义‘，就能够了。
咱们再来看看另外一种比拟常见的状况，就是通过 url 的形式来注入 js 代码，这个过后我在说的时候，把他说成能够通过参数，来获取页面的要害信息，没说明确，导致面试官可能了解有误，所以我也顺着他的思路说上来另外一种的形式，这个上面会讲。
如果咱们拜访的是: www.qq.com?id=222″;alert(1);”
let id = getQuery('id')
// 执行后果
let id = "1"; alert(1);""这样是不是就被执行了呢？
所以咱们能够通过对数据进行序列化 JSON.stringify(str), 这样就解决这个问题了。
咱们说了两个注入了，咱们接着说富文本的危险。咱们常常会应用 v -html 这个来用于渲染 dom 节点，这时候可能就有问题，如果咱们写了这样的代码点击 那这样的话就会触发 alert 弹窗，所以进攻富文本其实是一个比较复杂的事，所以咱们须要非凡解决 HTML 的代码，其实也能够通过第三方的库来实现，不必本人造轮子了，如 JS-XSS。
当然咱们常常应用的 VUE 中曾经有 XSS 进攻了，比方 URL 参数，尽量用 {{}} 这样通过了字符串化，浏览器不会对其中的内容进行执行操作。
重要的事件说三遍：尽量少用 v -html，尽量少用 v -html，尽量少用 v -html 如果用，必须提前对内容进行过滤。
四、CSRF 是个啥东东
Croos Site Request Frogy 指的是跨站申请伪造。与 XSS 不同的是，他会通过网站 B 来对指标网站 A 伪造申请。
例如 登陆了网站 A 之后，点击了一个歹意的链接 B，B 申请了网站 A 的下单接口，后果在网站 A 生成了一个 订单，其背地的原理就是网站 B 通过表单、get 申请来伪造网站 A 的申请，这时候申请会带上网站 A 的 cookies，若登陆态保留在 cookies 中，就是实现了伪造攻打。
产生的事件就比如说用户的登陆态被盗用，实现了业务的申请。
它的特点也很显著了，就是伪造申请不通过网站 A，伪造申请的域名不是网站 A
那对它的进攻绝对简略一些，能不应用 GET 申请就不应用。
还有就是 增加验证码，因为伪造申请不通过 A，所以咱们须要验证一下，这样通过验证的申请才非法。
针对第二个伪造申请不是 A 的状况，那么咱们将 cookies 设置为 sameSite 为 strict，只有同源网站的申请才会带上 cookies。
验证 reffer，后端能够通过 referrer 来验证。
验证 token，服务端随机生成 token，保留在服务器中的 session 中，同时保留到客户端中，客户端发送申请时，把 token 带到 HTTP 申请头或者参数中，服务端验证一下，token 与 session 中是否统一。
最初一种形式的话，就是通过 JWT 的计划来进攻，具体如何实现，看各位读者去实现了。
如果感觉不错，帮忙关注公众号！