浏览本文大略须要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的计划来进攻，具体如何实现，看各位读者去实现了。
如果感觉不错，帮忙关注公众号！