这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
一、本堂课重点内容：
本堂课的知识要点有哪些？
- 攻击篇
- 防御篇
二、详细知识点介绍：
Web安全
如 data leak; 个人信息的泄露会造成不法分子对我们信息的窃取，甚至做出一些匪夷所思的举措。
安全问题很常见，会危害到用户/公司/程序员自己
web安全的两个视角（hacker/开发者），因此本篇文章围绕攻击与防御两个方面展开
攻击篇
Cross-Site Scripting(XSS)
跨站脚本攻击：
在Web页面中，攻击者恶意注入script代码，在用户访问该页面时，这些恶意脚本就会被执行，达到攻击用户的目的，可能会造成用户隐私泄露或者用户被当成“挖矿”的机器。
XSS原理：
- 开发者盲目信任用户提交的内容；
- 前端工程师直接把用户提交的字符串转换成DOM
XSS的特点：
- 难以从UI上感知（暗地执行脚本）
- 窃取用户信息，如cookie、token
- 执行JS，绘制UI（如弹窗）
- 诱骗用户去点击和访问
XSS demo
XSS类型
Store XSS
存储型：把恶意脚本存在数据库里面，当用户访问页面时，就会去读取database中的数据，从而攻击用户；这是危害最大、对所有用户可见的恶意攻击。
- 恶意脚本被存在数据库中
- 访问页面→读数据 被攻击
- 危害最大，对全部用户可见
Reflected XSS
反射型：reflected，不涉及数据库，完全从URL攻击 如：host/path/?param=<script>alert('123')</script>，在服务端注入脚本
- 不涉及数据库
- 从URL上攻击
DOM-based XSS
- 不需要服务器参与
- 恶意攻击的发起+执行，全在浏览器完成
Reflected XSS VS DOM-based XSS
Mutation-based XSS
-
利用浏览器渲染DOM的特性
-
不同浏览器有区别
Cross-site request forgery(CSRF)
跨站点请求伪造：攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或者设定信息等的状态更新
CSRF特点
- 在用户不知情的前提下
- 利用用户权限（cookie）
- 构造指定HTTP全球，窃取或修改用户敏感信息
最常见的就是GET请求
Injection
最常见的是SQL注入攻击：在进行http请求时，恶意注入一段sql参数，服务器端将参数构造成SQL语句并运行SQL代码，代码被执行后就实现了SQL的恶意注入，可以用来获取、修改、删除数据
另外的注入攻击还有：
- CLI、
- OS command
- 以及原理相似的Server-Side Request Fprgery（SSRF，服务器端请求伪造）
Injection demo读取+修改
- 流量转发到真实第三方
- 第三方扛不住新增流量
- 第三方服务挂掉
- 您的竞争对手已下线
SSRF：访问callback，暴露内网信息
- 请求 用户自定义 的callback URL
- web server 通常有内网访问权限
Denial of Service(DoS)
服务拒绝，攻击者通过某种方式（构造特殊请求），导致服务器资源被大量消耗，使得更多请求无法响应，造成请求积压，进而引发雪崩效应
正则表达式的贪婪模式
重复匹配时 ？ VS no ？
满足“一个”或者“多个”：使用“?”满足一个即可，不用“?”有多少来多少
类型
-
ReDoS：基于正则表达式的DoS，贪婪模式，不断回溯
-
Logical Dos
- 耗时的同步操作
- 数据库写入
- SQL join
- 文件备份
- 循环执行逻辑
-
Distributed DoS(DDoS)：在短时间内使用大量僵尸设备请求流量，使得服务器不能及时完成所有请求，造成请求堆积引发“雪崩”，无法响应新请求
-
特点
- 直接访问IP
- 任意API
- 消耗大量带宽（耗尽）
中间人攻击
基于传输层的攻击方式，在浏览器和服务器之间插一个中间人来窃取、修改信息，进行网络请求
中间人攻击：
- 明文传输
- 信息篡改不可知
- 对方身份未验证
防御篇
Cross-Site Scripting(XSS)
原则：
- 永远不要信任用户提交内容
- 不能直接转换成DOM而是转换成字符串
XSS--工具
前端
- 主流框架都是默认防御XSS攻击的
- google-closure-library
服务端（Node）
- 使用DOMPurify
必须动态生成DOM
- new一个DOM的时候一定要对string进行转义
- 上传svg图片
- Blob动态生成script
- 尽量不允许用户自定义跳转行为
- 尽量不允许用户自定义样式
Same-origin Policy
协议、域名、端口都相同
内容安全策略CSP（Content Security Policy）
- 由开发者定义哪些源（域名）是安全的
- 来自安全源的脚本可以执行，否则直接抛出错误
- 对 eval+inline script 说NO
服务器响应头部
Content-Security-Policy: script-src 'self' https://domain.com
浏览器的meta
<meta http-equiv="Content-Security-Policy" content="form-action 'self';">
Cross-site request forgery(CSRF)
原则：
限制请求来源 -> 限制伪造请求
Origin + Referrer 形式
校验token，token应该设置有效期
iframe攻击：
限制Origin，则同源请求
X-Frame-Options: DENY（不能加载iframe）/ SAMEORIGIN（必须同源）
anti-pattern：
GET！=GET + POST
避免用户信息被携带：SameSite Cookie：
“我页面的Cookie只能为我所用”，从根源解决
限制条件：
Cookie domain属性 当前页面域名是否匹配
第一方Cookie ✔；第三方Cookie ✘
依赖第三方Cookie服务怎么办
Set -Cookie: SameS ite=None; Secure;
从node层面讲：
生成中间件，专门防御CSRF
Injection
- 找到项目中查询SQL的地方，使用prepared statement
Injection beyond SQL
- 最小权限原则 sudo || root
- 建立白名单 rm
- 对URL类型参数进行协议、域名、ip的限制 访问内网
Denial of Service(DoS)
基于正则：
- 避免贪婪匹配；
- 使用代码扫描工具，进行正则性能测试
- 拒绝用户使用的正则
防御关键：
流量治理
过滤：
- 负载均衡
- API网关
抗量：
- CDN
- 快速扩容
- 非核心服务降级
传输层 防御中间人：
使用https
https特点：
可靠（TLS加密层）
完整（MAC验证）
不可抵赖（数字签名）
HTTP strict-Transport-Security (HSTS)
将http主动升级成https，需要先有一次https请求
Subresource Integrity (SRI)
静态资源被劫持篡改？
对比hash
