这是我参与「第四届青训营 」笔记创作活动的第2天
XSS攻击
原因
- 将用户上传的内容盲目转换为DOM
特点
- 窃取用户的信息cookie/token
- 绘制UI（如弹窗），诱骗用户点击/填写表单
类别
1.存储型xss
- 恶意脚本被存在数据库中，危害最大，对全部用户可见
2.反射型xss攻击
- 不涉及数据库，从URL上进行攻击 ，例如param传入js字段
3.基于DOM的xss攻击
- 不需要服务器的参与，恶意攻击的发起和执行都在浏览器端完成
- 与反射型的区别，反射性在服务端注入脚本，基于DOM的在浏览器完成
4.基于Mutation的xss攻击
- 利用了浏览器渲染DOM的特性（独特优化）
- 不同浏览器，会有区别（按照浏览器进行攻击）
- 例如：
<noscript><p title="</noscript><img src="x" onerror=alert(1)>">
渲染之后：
<nodcript><p title="</noscript>
<img src="x" onerror=alert(1)>
">
其中<p title="被渲染为文本，<img src="x" onerror=alert(1)>被渲染成标签
防御
永远不要相信用户提交的内容，永远不要将用户提交的内容渲染为Dom 使用现成工具：主流框架如vue默认防御xss攻击
若用户需求是 根据传递的文本 动态生成DOM
- 对svg图片进行扫描
- 尽量不允许用户自定义跳转链接
- 用户自定义样式也会导致xss攻击
- 要谨慎使用带url属性的样式
CSRF跨站伪造请求
特点
- 用户在不知情的前提下
- 利用用户权限cookie
- 构造指定HTTP请求，窃取或修改用户敏感信息
get请求方式
用户点击a标签，完成get请求，进行攻击
<a href="https://bank.com.transfer?to=hacker&amount=100">点我抽奖</a>
用户访问页面，图片加载完成发送get请求，完成攻击
<img style="display:none;" src="https://bank.com.transfer?to=hacker&amount=100" />
防御
同源策略
- 进行同源检测：请求来源是异常来源，所以可以针对接口请求的referrer或origin进行校验，但同源请求中，不发送origin字段。
- CSRF Token 进行验证：
- 对 Cookie 进行双重验证
iframe攻击
iframe中发送的不是跨域请求，而是同源请求
http响应头部设置deny/SAMEOOOOO
GET!==GET+POST
避免让get接口能同时处理get和post
在设置 cookie 属性的时候设置 Samesite
在设置 cookie 属性的时候设置 Samesite ，限制 cookie 不能作为被第三方使用，从而可以避免被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用，在宽松模式下，cookie 可以被请求是 GET 请求，且会发生页面跳转的请求所使用。
什么是Samesite Cookie？
依赖Cookie的第三方服务怎么办？
Samesite与CORS跨站资源有什么区别？
node角度
CSRF方法很多，不要一个个设置，利用中间件设置
SQL Injecttion 注入
向数据库请求信息时，SQL参数中写入SQL语句，服务器运行这段SQL语句代码，对数据库信息进行修改
防御
- 最小权限原则
- 建立允许名单+过滤
DoS
通过某种特定方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩。
基于正则表达式的Dos
贪婪模式的正则表达式，不断进行回溯匹配，使服务器响应时间延长，消耗资源
防御
code review 拒绝贪婪模式等 代码扫描，测试正在表达式性能 拒绝用户的正则表达式
DDos
短时间内来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，进而雪崩效应，无法响应新请求。
- 攻击特点：1，直接访问IP；2.任意API接口；3.消耗大量带宽。如洪水攻击，发大量SYN请求
防御
流量治理 过滤和抗量
传输层--中间人攻击
中间人可以是恶意浏览器，路由器，运营提供商 利用了 明文传输，不验证身份的特点
防御
https：可靠性、完整性、不可抵赖性：数字签名 或者http3内置了tts
扩展思考
CDN静态资源存放，如果静态资源被劫持篡改怎么办
使用hash值进行hash计算，判断两者的值是否相同
