这是我参与「第四届青训营 」笔记创作活动的的第4天
web安全这个问题，比我们想象的常见的多，作为一位开发者，了解与解决安全问题是必须的。那么我们从攻击和防御两个角度来了解Web安全问题
✔XSS 跨站脚本攻击
全称Cross-Site Scripting。
⭐攻击行为
在一个开发维护页面中，攻击者/用户通过某种方式将恶意脚本注入进来。造成的风险可能有用户隐私泄露或者用户被错误识别。
XSS主要利用开发者盲目信任用户提交的信息，例如将提交的信息直接转化为DOM，导致在页面中插入一段可能为恶意网址的跳转链接或者是一段可运行脚本来窃取用户信息
特点
分类
1. 存储型 stored XSS
危害最大，可能所有用户都可见
2.反射型 Reflected XSS
它不涉及到数据库，直接从URL上进行攻击
比如下图中例子，param参数将有query参数赋值而来，如果攻击者修改了query内容，插入一段恶意脚本，就可能导致问题出现
3.基于DOM型 DOM-based XSS
DOM型与反射型的区别
完成注入脚本的地方不同 反射性的脚本实际上是在服务端传输到客户端 而DOM完全由浏览器这一端来操作
4.基于浏览器型 Mutation-based XSS
它通过不同浏览器渲染页面结点的不同方法，来钻过检查漏洞将恶意脚本注入，这也是最难防御的一种攻击方式
⭐防御
永远不要相信用户提交的信息，将用户提交的内容转换为字符串插入，而不是转化成DOM结点
但是如果有某些需求必须要动态生成DOM，我们要注意，一定要先进行安全过滤与扫描，不允许用户自定义跳转链接
CSP内容安全策略
✔CSRF 跨站伪造请求
Cross-site request forgery
⭐攻击行为
比如一些恶意网站，用户点击了该网站，恶意网站直接窃取该用户的某网站cookie或者其他权限，然后使用该信息伪造http请求，更改窃取服务器端的信息
⭐防御
限制请求来源，校验域名是不是一致的，如果不是正确的域名，直接拒绝访问
token方式
当用户第一次请求页面是，服务器返回页面+token，下一次访问页面是，需要将token连通访问请求一并返回到服务器端，当token校验成功，才返回请求
iframe 同源恶意请求防御
直接设置响应头信息，拒绝iframe请求
Same-site Cookie方式
根源解决scrf工具
✔Injection 注入攻击
⭐攻击行为
最常见的注入攻击为SQL注入，也就是将恶意信息直接注入数据库
比如说直接在客户端向后端发送请求去调用数据库，将删库等语句直接注入数据库，这样，我们就完成了删库跑路成就🤣
⭐防御
建立白名单 提前编译检查
✔Dos 服务拒绝攻击
⭐攻击行为
⭐防御
