这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天 冲冲冲！
攻击篇
Cross-Site Scripting XSS
- 通常难以从UI上感知
- 窃取用户信息
- 绘制UI(例如弹窗)，诱骗用户点击/填写表单
Stored XSS
- 恶意脚本被存在数据库中
- 访问页面->读数据 === 被攻击
- 危害最大，对全部用户可见
Reflected XSS
- 不涉及数据库
- 从URL上攻击
DOM-based XSS
- 不需要服务器的参与
- 恶意攻击的发起+执行，全在浏览器完成
Mutation-based XSS
- 利用了浏览器渲染DOM的特性(独特优化)
- 不同浏览器会有区别(按浏览器进行攻击)
Cross-site request forgery(CSRF)
- 在用户不知情的前提下
- 利用用户权限(cookie)
- 构造指定HTTP请求，窃取或修改用户敏感信息
SQL Injection
Injection 不止于 SQL
- CLI
- OS command
- Server-Side Request Forgery(SSRF),服务端伪造请求
- 严格而言，SSRF不是injection，但是原理类似
Denial of Service(DOS)
通过某种方式(构造特定请求)，导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应
ReDoS：基于正则表达式的DOS
Logical DOS
- 耗时的同步操作
- 数据库写入
- SQL join
- 文件备份
- 循环执行逻辑
DistributedDOS(DDOS)
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求
- 攻击特点
- 直接访问IP
- 任意API
- 消耗大量带宽(耗尽)
中间人攻击
防御篇
XSS
-
永远不信任用户提交的信息
- 不要将用户提交内容直接转换成DOM
-
XSS--现成工具
- 前端
- 主流框架默认防御 XSS
- google-closure-library
- 服务端(Node)
- DOMPurify
- 前端
CSRF的防御
我们知道，csrf是通过伪造请求，那么我们可以通过限制请求来进行防御，伪造请求就判定为异常来源
除了origin + referer还有没有其他的方式来限定呢？
CSRF--token
在我们平时浏览网页时，如果是一些需要登录的网站，那么在登录的时候，浏览器发送给服务器我们的账号密码，然后服务器通过我们的账号密码生成一个唯一标志服token，这个token是通过特殊加密的方式，不能反推出用户的账号密码。那么服务器返回的这个token就会在我们的每一个网站内的网页间跳转携带，从而每次加载页面都可以验证token，验证不通过就会拒绝请求，保证我们的信息唯一。通过token就可以有效防止伪装的信息
CSRF--iframe攻击
iframe类似于一个透明的遮罩，当用户点击页面的button时，实际上是点击的那个透明的iframe，这个时候就能拿到用户的token，请求地址也是合法的
这个就可以通过下面的一个选项，页面能不能通过iframe，deny就是不允许，通过设置也可以限制iframe的攻击
CSRF anti-pattern
GET!==GET+POST
