1-1、Xss跨站脚本攻击：黑客通过html注入篡改网页、插入脚本来控制用户浏览器的攻击
它们可分为：存储型、反射型、dom型
①、存储型Xss：代码存储在服务器端(用户信息、文章发表等地)，如果服务器未过滤或者过滤不严，
其他用户触发这些代码的时候，就会导致cookie窃取等攻击。
②、反射型Xss：让用户点击后发生Xss，一般出现在搜索页面，非法用户可能用恶意脚本的url来收
集用户信息。
③、Dom型Xss: 利用Dom这个与平台、语言无关的接口，改变页面的展示。利用Dom的一些属性来修改
浏览器展示。
1-2、Xss的防范
①、创建白名单，将敏感边角字符替换成全角字符：如< script >、&、#、%等都进行全角字符替换。
②、对输出进行编码：对动态输出到页面上的内容都进行转义和编码；
③、react中慎用dangerouslySetInnerHtml方法：React Dom在渲染所有输入内容时，默认转义
string类型
④、url检测：href、src的值必须以http://开头，白名单中不能有10进制和16进制编码字符；
⑤、对Cookie设置http-only：js脚本不能读取cookie，减轻Xss发生后的Cookie挟持；
2-1、Csrf跨站请求伪造：挟持用户在当前已登录的web应用上执行恶意操作的攻击
举例如下
①、当用户进入银行站点’www.bank.com'
②、用户登录，输入账号密码，http请求成功；服务器在响应头set-cookie字段设置sessionId，
即用户身份证，之后的用户请求会携带sessionId以便服务器鉴权。
③、银行提供一个借口用与转账如：’www.bank.com/out?money=转账数&to=目标账户'
④、用户被不小心诱导、重定向打开’www.zjj.com',此网站的html存在一段攻击脚本:
< script src = ‘www.bank.com/out?money=1&to=zjj' />
浏览器会指向js脚本，通过http请求加载js，并且会同时携带上用户登录设置的sessionId；
⑥、账户请求转账接口导致攻击生效
2-1、Csrf防御的传统方式
核心：http请求时，同一个域下的cookie会携带在请求头里提交
①、设置验证码，让用户和应用强制交互。
②、服务器检查http请求头的字段Reference是否以’www.c.com'开头（从哪个页面的url发送的
请求）
③、服务器检查http请求头的字段Origin（从哪个网站host发送的请求）
④、使用token令牌，表单的提交一般带一个随机token，告诉服务器这是真实的请求
⑤、http响应头部设置cookie的secure属实，限制cookie在https下传输
2-2、防范Csrf新特性：服务器响应头Set-cookie：SameSite属性
出现原因：请求头的reference可伪造等因素
①、SameSite=Lax,chrome计划将lax设置为默认值，只有同站请求时发送cookie；
②、SameSite=Strict，只有同url请求时发送cookie(过于严格，例如用户跳转url，不会带上附
加登陆状态的cookie)；
③、SameSite=None, 跨站请求、同站请求都发送cookie(即sameSite失效，存在跨站请求伪造攻
击可能)；
2-3、浏览器如何区分同站与跨站?
①、浏览器依靠eTLD+1的策略来区分同站。且依赖于一个公共后缀列表，里面会记录一系列属于同站
的域名信息。
②、浏览器会根据公共后缀列表，来对url进行判定是否属于’同站’，步骤为:
一、按’.’将url分割为三部分；
二、首先遍历公共后缀列表，从url第一个分隔部分开始，查找是否有匹配部分;
三、若没找到，则向url分隔的其余部分继续查找，是否有与列表匹配的；
四、若找到，则浏览器记录此url为一个eTLD（TLD代表’top level domain,即
顶级域，eTLD则代表公共的TLD部分，而eTLD往前截取的那个部分，浏览器记录为一个’1’)
五、浏览器通过比较eTLD+1是否相等，来比较url是否属于同站。