这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
XSS
- 永远不信任用户的提交内容
- 不要将用户提交内容直接转换成 DOM
现成工具
前端
- 主流框架默认防御 XSS --- 例如vue
- google-closure-Library
服务端 (Node)
- DOMPurify
那我遇到某些需求，必须动态生成DOM的时候呢？例如我最近做的md转html
string
对string进行转译
svg
对svg进行扫描，因为svg可以插入script标签
Blob 动态生成script
- 尽量不要让客户做自定义跳转的行为
Content Security Policy(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 的防御
在服务器端，可以通过origin和referer进行校验，如果origin和referer是我的域名，则就放行这个请求，否则拒绝
token
- 浏览器端先向服务器端发送一个请求页面的请求
- 然后服务器端返回页面+token
- 浏览器之后请求API的时候会带上token
- 服务器验证通过后会返回真实数据
iframe 攻击
攻击者会构造一个iframe，里面有一个button
这里的button设置pointer-events这个css属性，由于btn的事件被阻止了，那么点击的时候事件会穿越到父元素的iframe中
那遇到这种iframe攻击，该如何防御呢？
在服务端可以设置
X-Frame-Options: DENY /SAMEORIGIN
anti-pattern
避免get请求和post请求写在一起
SameSite Cookie
第一方cookie，简单来说：限制第三方cookie
依赖 Cookie 的第三方服务怎么办？ 内嵌一个 X站播放器，识别不了用户登录态，发不了弹幕
在服务器端可以这样设置：
Set-Cookie: SameSite=None；Secure；
SameSite vs CORS
Injection
- 找到项目中查询 SQL 的地方
- 使用 prepared statement
提前将sql语句编译让其不能通过
SQL
-
最小权限原则
- 🈲️ sudo｜｜root
-
建立允许名单 + 过滤
- 🈲️ rm
-
对 URL 类型参数进行协议、域名、ip 等限制
- 🈲️ 访问内网
Regex Dos
- Code Review ( 拒绝贪婪匹配 / (ab* )+/)
- 代码扫描 +正则性能测试
- 🈲️ 用户提供的使用正则
DDoS
传输层一一防御中间人
- 使用HTTPS
HTTPS特性
- 可靠性：加密
- 完整性：MAC 验证 hash验证
- 不可抵赖性：数字签名
HTTP Strict-Transport-Security (HSTS)
- 将HTTP 主动升级到HTTPS
Subresource Integrity(SRl)
如果我们的cdn被劫持、串改怎么办？可以通过SRI来解决
- 首先在script上添加integrity属性，这样浏览器拿到资源时会进行一次hash计算
总结
虽然防御手段大多数都是服务端# Web 开发的安全之旅 —— 防御篇有些漏洞和攻击可能都是我们没想到的，所以我们要保持学习心态，持续学习~~
