攻击篇
Cross-Site Scripting(XSS)
概念：通过在页面中插入不属于开发者的js脚本来实现的跨站脚本攻击
xss主要是因为我们盲目信任用户的提交内容，没有将用户提交内容进行过滤/转义，直接转化成DOM
特点：
- 通常难以从UI上感知（暗地执行脚本
- 窃取用户信息(cookie/token)
- 绘制UI（例如弹窗），诱骗用户点击/填写表单
案例：
类别1：Stored XSS
- 恶意脚本被存在数据库中
- 访问页面→读数据===被攻击
- 危害最大，对全部用户可见
类别2：Reflected XSS
- 不涉及数据库
- 从URL上攻击
类别3：DOM-based XSS
他和reflected完成注入脚本的地方是不同的
类别4：Mutation-based XSS
- 利用了浏览器渲染DOM的特性（独特优化）
- 不同浏览器，会有区别（按浏览器进行攻击）
它把脚本写到了我们不太会去过滤的title里，但是由于浏览器的特性，有些时候里面的标签还会被渲染。
Cross-site request forgery(CSRF)
在用户不知情的前提下，利用用户权限（cookie），构造指定HTTP请求，窃取或修改用户敏感信息
过程：
- 用户没有访问银行页面
- 银行页面中的特定接口被请求
- 请求执行成功
GET
beyond GET
Injection
SQL注入
这个代码里，读取请求字段后直接以字符串的形式拼接了SQL语句
除了SQL注入，还有很多的注入情况可能发生
- CLI
- OS command
- Server-Side Request Forgery(SSRF),服务端伪造请求（严格而言，SSRF 不是 injection,但是原理类似）
这个代码里，options可能可能被恶意传入系统操作命令，就会出问题
同时，如果被修改了nginx文件，会导致用户的服务被导向错误的地方，导致网站被错误访问
这个是SSRF，这里请求【用户自定义】的 callback URL，这个web server 通常有内网访问权限，可能暴露内网信息。
Denial of Service(DoS)
指通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。
案例一：基于正则表达式的贪婪模式，让正则表达式不断回溯，导致响应时间增加，接口吞吐量降低
案例二：Logical Dos
- 耗时的同步操作
- 数据库写入
- SQL join
- 文件备份
- 循环执行逻辑
Distributed DoS(DDoS)
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求
「不搞复杂的，量大就完事儿了」
特点：
- 直接访问IP
- 任意 API
- 消耗大量带宽（耗尽）
案例：
基于传输层的攻击方式
中间人攻击：明文传输；信息篡改不可知；对方身份未验证
防御篇
XSS
永远不信任用户的提交内容，—不要将用户提交内容直接转换成DOM
前端：主流框架默认防御XSS；google-closure-library
服务端Node：DOMPurify
注意点：
- 转义：如果必须要动态根据用户的内容生成dom，那么必须注意转义成string。
- svg：svg内是允许有script的
- 自定义样式：background等可以访问url的
- 自定义跳转链接：href的地址
Content Security Policy(CSP)
- CSP允许开发者设置哪些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对 eval + inline script 可以直接报错
CSRF
对请求来源进行限制
除了 Origin + Referrer，其他判断【请求来自于合法来源】的方式还有：
这个由于先有页面后有请求，可以通过Token限制合法请求
iframe攻击：iframe中的请求是不会被认为跨域的
防御方式可以是使用在服务端渲染页面时限制请求为X-Frame-Options: DENY/SAMEORIGIN
SameSite
通过SameSite Cookie来避免用户信息被携带，也可以防止CSRF攻击
但是，这样的问题是，如果内嵌一个Ⅹ站播放器（依赖Cookie的三方服务），识别不了用户登录态，发不了弹幕
解决方案是部分需要被携带的Cookie设置为none，则可以被携带
SameSite vs CORS
防御Injection
- 找到项目中查询SQL的地方
- 使用 prepared statement
防御Dos
Regex DoS
- Code Review，避免出现类似(/(ab*)+/)的正则表达式（贪婪匹配）
- 代码扫描+正则性能测试
- 不使用用户提供的正则
Logical DoS
- 不是非黑即白：有些case，只有在请求量大到一定之后，才会体现
- 分析代码中的性能瓶颈：同步调用、串行逻辑、CPU密集型操作
- 限流
防御DDos
防御中间人（传输层）
使用HTTPS
- 可靠性：加密（拒绝明文）
- 完整性：MAC验证（拒绝篡改）
- 不可抵赖性：数字签名（身份校验）
HTTPS流程：
完整性：
不可抵赖性-数字签名：
CA: Certificate Authority 证书机构
数字签名在HTTPS中的工作
要注意，当签名算法不够健壮时，证书签名也是有可能被破解
将HTTP主动升级到HTTPS的方法：HTTP Strict-Transport-Security (HSTS)
Subresource Integrity (SRI)
通过对比哈希值防止js、css文件等被篡改
尾声
- 安全无小事
- 使用的依赖（npm package，甚至是 NodeJS）可能成为最薄弱的一环 npm install 除了带来了黑洞，还可以带来漏洞
推荐读物
