这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
一、Web开发的安全之旅之防御篇
1.1 XSS 防御
- 永远不要相信用户提交的任何内容
- 不要将用户提交内容直接转换为DOM
1.2 XSS——现成防御工具
前端
- 主流框架（React、Vue）默认防御XSS
- google-closure-library
服务端
- 对应的包——DOMPurify
1.3 用户需求必须动态生成DOM下XSS攻击情形
第一种：string——>DOM
- 使用new DOMParser()类似API前必须将字符串进行转译
第二种：允许用户上传svg
- 提前扫描svg标签，防止中间插入script脚本恶意代码
第三种：自定义跳转链接
- 尽量不要让用户自定义跳转行为，如果做也一定要提前过滤
第四种：自定义样式
- 攻击者通过伪造一个CSS代码在指定情况下来发送一个请求，而导致攻击
1.3 Content Security Policy(CSP)
内容安全策略(CSP)
- CSP允许开发者去定义那些源 域名被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval + inline script 直接抛错
CSRF的防御
限制请求来源：服务器端开发人员可以校验接收的Origin或者Referer进行校验，如果是当前服务器的域名那么就放行请求，如果不是则拒绝请求
token
在服务器接收到一个合法页面请求时，服务器可以通过标识来判断是否是一个合法来源的请求，具体流程为：
- 浏览器先向服务器发送一个页面的请求
- 服务器接收到这个请求后，会返回页面以及一个token给浏览器
- 浏览器之后在请求任意API的时候还会把这个token带上
- 服务器之后会对这个token进行校验，如果校验不通过，那么直接报错不返回具体数据，如果校验通过则返回真实数据
注：
- token往往和用户是进行绑定的：攻击者也可以是注册用户===可以获取自己的的token
- token有过期时间：保证token的丢失不会影响到用户前后信息
iframe攻击
- 限制Origin，攻击者会使用同源请求来到达攻击
- 使用iframe来到达绕过Origin限制达到攻击
。。。。。。。
