这是我参加青训营的第11天
分享要点：
一、攻击篇 1.XSS2.CSRF 3.SQL 注入 4.SSRF 5.DoS 6.中间人攻击
跨站脚本攻击：在Web页面中，攻击者恶意注入script代码，在用户访问该页面时，这些恶意脚本就会被执行，达到攻击用户的目的，可能会造成用户隐私泄露或者用户被当成“挖矿”的机器。
XSS主要利用
开发者盲目信任用户提交的内容；
前端工程师直接把用户提交的字符串转换成DOM
XSS特点
难以从UI上感知（暗地执行脚本） 窃取用户信息，如cookie、token 执行JS，绘制UI（如弹窗） 诱骗用户去点击和访问
XSS类型
存储型：把恶意脚本存在数据库里面，当用户访问页面时，就会去读取database中的数据，从而攻击用户；这是危害最大、对所有用户可见的恶意攻击
反射型：reflected，不涉及数据库，完全从URL攻击 如：host/path/?param=，在服务端注入脚本
基于DOM的：无需服务器参与，“注入+攻击”由浏览器完成
基于Mutation的：利用浏览器渲染DOM的特性，不同浏览器有所差异，非常巧妙、最难防御的攻击跨站点请求伪造：攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或者设定信息等的状态更新
CSRF特点
用户不知情
利用用户权限（cookie、token等）构造http请求
窃取或修改用户信息
最常见的就是GET请求
Injection
最常见的是SQL注入攻击：在进行http请求时，恶意注入一段sql参数，服务器端将参数构造成SQL语句并运行SQL代码，代码被执行后就实现了SQL的恶意注入，可以用来获取、修改、删除数据
另外的注入攻击还有：CLI、OS command，以及原理相似的Server-Side Request Fprgery（SSRF，服务器端请求伪造）
删除
读取、修改，通过把自己的网站代理转换成另一个第三方网站，把流量牵引过去，如果第三方承受不住就会导致服务器over，竞争对手GAMEOVER
SSRF：访问callback，暴露内网信息 Denial of Service(DoS)
服务拒绝，攻击者通过构造特殊请求，大量消耗服务器资源，使得更多请求无法响应，造成请求积压，引发雪崩效应
回顾一下：正则表达式的贪婪模式
满足“一个”或者“多个”：使用“?”满足一个即可，不用“?”有多少来多少 类型
ReDoS：基于正则表达式的DoS，不断回溯
Distributed DoS(DDoS)：最常见的，在短时间内使用大量僵尸设备请求流量，使得服务器不能及时完成所有请求，造成请求堆积引发“雪崩”，无法响应新请求
特点
不会限制在域名的访问，更多的是直接访问IP
目的：耗尽带宽，eg：三次握手
耗时的同步操作、数据库写入、文件备份、循环执行逻辑
中间人攻击
基于传输层的攻击方式，在浏览器和服务器之间插一个中间人来窃取、修改信息，进行网络请求
中间人攻击利用：明文传输、信息篡改不可知、对方身份未验证 二、防御篇 1.SameSite Cookie 2.HTTPS 3.HSTS 4.CSP 5.SRI
跨站脚本攻击XSS防御 原则：永远不要信任用户提交内容，不能直接转换成DOM而是转换成字符串
前端主流框架都是默认防御XSS攻击的，也有工具：google-closure-library
服务端（Node）使用DOMPurify
如果非要动态生成DOM
new一个DOM的时候一定要对string进行转义 扫描svg图片 尽量不允许用户自定义跳转行为 内容安全策略CSP（Content Security Policy）
基于同源策略：协议、域名、端口都相同
CSP
由开发者定义哪些源是安全的，安全源脚本可以执行，非安全源的抛出错误
服务器响应头部
Content-Security-Policy: script-src 'self' domain.com
浏览器的meta
CSRF的防御 原则：限制请求来源 => 限制伪造请求
Origin + Referrer 形式
校验token，token应该设置有效期
iframe攻击：http响应头 ，X-Frame-Options: DENY（不能加载iframe）/ SAMEORIGIN（必须同源）
anti-pattern：不能将GET、POST写成同一个
SameSite Cookie：“我页面的Cookie只能为我所用”，从根源解决
限制条件：Cookie domain属性和当前页面域名是否匹配
第一方Cookie ✔；第三方Cookie ✘
依赖第三方Cookie服务怎么办
Set -Cookie: SameS ite=None; Secure;
从node层面讲：生成中间件，专门防御CSRF
Injection
找到项目中查询SQL的地方，使用prepared statement
最小权限原则
建立白名单
对URL类型参数进行协议、域名、ip的限制
DoS
基于正则：避免贪婪匹配；使用代码扫描工具，进行正则性能测试；拒绝用户使用的正则
防御关键：流量治理、快速扩容、非核心服务降级
传输层
防御中间人：使用https
https特点：可靠（TLS加密层）、完整（MAC验证）、不可抵赖性（数字签名）
HSTS 将http主动升级成https，需要先有一次https请求
