这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
XSS 的防御
永远不要信任用户的提交内容
不要将用户提交内容直接转换成DOM
XSS —— 现成工具
- 前端
- 主流框架默认防御 XSS
- google-closure-library
- 服务端
- DOMPurify
警惕
⚠️⚠️string → DOM
要进行转译
⚠️⚠️上传 svg
对svg文件进行一次扫描
svg图片中可以插入script标签，如果svg图片被加载，script标签会被执行，完成一次XSS攻击
⚠️⚠️Blob 动态生成 script
尽量不要做让用户自定义跳转的行为，如果要做，请做好过滤。
如果允许自定义跳转链接，可以传递js代码
内容安全策略（CSP）
- 允许开发者定义哪些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对 eval + inline script 说 🚫🚫
服务器的响应头部
Content-Security-Policy: script-src 'self' 同源
Content-Security-Policy: script-src 'self' https://domain.com
浏览器meta
<meta http-equiv="Content-Security-Policy" content="script-src self">
CSRF 的防御
伪造请求来源是异常来源，限制请求来源可以限制 CSRF 攻击
作为服务器端开发人员，可以针对接口请求，对Origin或Referer进行校验，若Origin或Referer是自己的
域名，便放行此请求，若不是，便拒绝这个请求。
- if 伪造请求 === 异常来源
- then 限制请求来源 → 限制伪造请求
- Origin
- 同源请求中，GET + HEAD 不发送
- Referer（更广泛的被利用）、
CSRF —— token
如果一个请求来自于一个合法页面（服务器接受过相关页面的请求），服务器在接收这个页面请求时，可以进行一些标记
| 🤔 除了 Origin + Referer 其他判断【请求来自于合法来源】的方式 |
|---|
| if（请求来自合法页面） then（服务器接受过页面请求） then（服务器可以标识） |
| 先有页面，后有请求 |
CSRF —— iframe 攻击
攻击者构造一个页面，页面上有一个<button>标签，<button>下盖着一个 iframe（我们的合法页面），用户点击<button>，点击行为被穿越到 iframe 中，iframe 之中可能因受到点击而发出一个http请求，因为 iframe 中发生的请求不是跨域请求，是同源请求，所以对应的攻击完成了。
防御 CSRF 的正确姿势
从 node 的角度讲，做一个中间件，这个中间件专门生成防御 CSRF 的策略，就在一处保证整个 Web app 对 CSRF 的防御。
防御 Injection
- 找到项目中查询 SQL 的地方
- 使用 prepared statement
PREPARE q FROM 'SELECT user FROM users WHERE gender = ?';
SET @gender = 'female';
EXECUTE q USING @gender;
DEALLOCATE PREPARE q;
Injection beyond SQL
- 最小权限
- sudo || root
- 建立允许名单 + 过滤
- rm
- 对 URL 类型 参数进行协议、域名、ip 等限制
- 访问内网
防御 DoS
Regex Dos
- Code Review （❌ / (ab*) + /）
- 代码扫描 + 正则性能测试
- ❌ 用户提供的使用正则
DDos
- 流量治理
- 负载均衡 ⬅️过滤
- API 网关 ⬅️过滤
- CDN ⬅️抗量
在【负载均衡\API 网关】进行一些流量的识别，将恶意攻击进行过滤（转到其他服务、直接拒绝）
前置 CDN，所有流量都要过 CDN，再到具体的服务
- 快速自动扩容 ⬅️抗量
- 非核心服务降级 ⬅️抗量
传输层 —— 防御中间人
HTTPS 的一些特性
- 可靠性：加密
- 避免了明文传输
- 完整性：MAC 验证
- 确保信息没有被篡改
- 不可抵赖性：数字签名
- 确保双方身份可被信任
银烛秋光冷画屏，轻罗小扇扑流萤。
