这是我参与「第五届青训营 」伴学笔记创作活动的第5天
3防御篇
3.1 针对XSS
-
永远不要相信用户提交的内容
- 不要讲用户提交内容直接转换成DOM
3.1.1XSS——现成工具
前端
- 主流框架默认防御XSS
- google-closure-library
服务端（Node）
- DOMPurify
3.1.2XSS——用户要求
【用户要求】必须动态生成DOM
3.1.2.1string直接生成DOM
对string进行转移
new DOMParse();
3.1.2.2上传svg
对svg文件进行扫描
<svg>
<script>alert('xss');</script>
</svg>
3.1.2.3Blob动态生成script
3.1.2.4自定义样式
同源策略：Same-origin Policy
- 协议
- 域名
- 端口
http请求：同源OK，跨域No
3.2Content Security Policy（CSP）
csp：内容安全策略
- 哪些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval+inline script 说 No
3.2.1 CSP
服务器的响应头部
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'>
3.2.2 CSRF的防御
if 伪造请求 全等于≡ 异常来源
then限制请求来源->限制伪造请求
请求头部：
-
Origin
同源请求中，GET+HEAD不发送
-
Referer
3.2.2.1 CSRF——token
除了Origin+Referer
其他判断【请求来自于合法来源】的方式
if（请求来自合法页面）
then（服务器接收过页面请求）
then（服务器可以标识）
3.2.2.2 CSRF——iframe攻击
攻击者：限制Origin是吧，那我同源请求
3.2.2.3 CSRF anti-pattern
GET !== GET+POST
攻击者一石二鸟
开发者不能偷懒
3.2.3避免用户信息被携带：SameSite Cookie
3.2.3.1SameSite Cookie
- 依赖Cookie的第三方服务怎么办？
- 内嵌一个X站播放器，识别不了用户登陆态，发不了弹幕
Set-Cookie:SameSite=None;Secure;
3.2.3.2 SameSite vs CORS
| SameSite | CORS |
|---|---|
| Cookie发送 | 资源读写（HTTP请求） |
| domain vs 页面域名 | 资源域名vs页面域名 |
| “我跟你说个事儿，出这屋我可就不认了” | 白名单 |
3.2.3.3SameSite demo
FirstPartyCookie
3PartyCookie
3.3 Injection
- 找到项目中查询SQL的地方
- 使用prepared statement
3.3.1 Injection beyond SQL
-
最小权限原则
sudo||root
-
建立允许名单+过滤
rm
-
对URL类型参数进行协议、域名、IP等限制
访问内网
3.4防御DoS
3.4.1 Regex DoS
- Code Review ( 拒绝 /(ab*)+/ )
- 代码扫描+正则性能测试
- 拒绝用户提供的使用正则
3.4.2 DDoS
-
流量治理
负载均衡 （过滤）
API网关 （过滤）
CDN （抗量）
-
快速自动扩容 （抗量）
-
非核心服务降级（抗量）
3.5 传输层——防御中间人
3.5.1HTTPS的一些特性
- 可靠性：加密
- 完整性：MAC验证
- 不可抵赖性：数字签名
3.5.2HTTPS——完整性
传输内容（加密信息+加密信息_hash）——>接收方
if(hash(加密信息)≡加密信息_hash){
ok
}else{
not ok
}
数字签名
签名执行者:
- privateKey(自己藏好)
- publicKey(公开可见)
3.5.3HTTPS——不可抵赖：数字签名
CA：Certificate Authority证书机构
