@blueking/bkui-knowledge 0.0.1-beta.1 → 0.0.1-beta.10

package/knowledge/skills/web-security-guide/references/access-control.md

@@ -0,0 +1,123 @@
+# 访问控制缺失
+
+## 1. 漏洞原理
+
+- 访问控制缺失（Broken Access Control）是指应用未对用户访问的功能或资源进行严格的 身份认证与权限校验，导致攻击者可以越权访问、操作他人数据或调用敏感功能。
+
+- 常见问题：
+  - 鉴权仅在前端或网关，后端未做校验。
+  - ID 可控（IDOR，Insecure Direct Object Reference）。
+  - 垂直越权（普通用户可调用管理员接口）。
+  - 鉴权逻辑存在绕过漏洞（路径编码、大小写、截断）。
+
+## 2. 漏洞影响
+
+- 水平越权：攻击者可读取/修改其他用户的数据（如查看他人订单、转账记录）。
+- 垂直越权：普通用户可调用管理员功能（如创建用户、删除数据）。
+- 内部绕过：通过内网直连后端，绕过网关鉴权。
+- 逻辑绕过：利用路径大小写、编码差异，绕过黑名单/路径匹配规则。
+
+## 3. 典型业务场景
+
+### 3.1 功能隐藏在前端 UI，但后端未鉴权
+
+- 前端页面隐藏"导出数据"按钮，但后端接口 /admin/export 无鉴权。
+- 攻击者直接访问接口即可导出敏感数据。
+
+### 3.2 API 可越权访问其他用户数据（IDOR）
+
+- URL 参数可控：/api/user/profile?id=1002。
+- 用户 A 修改参数即可获取用户 B 的信息。
+
+```
+GET /api/user/profile?id=1001  # 合法
+GET /api/user/profile?id=1002  # 越权读取
+```
+
+### 3.3 水平越权：用户可修改 URL 参数访问他人资源
+
+- 类似 IDOR，但更广：订单、合同、文件下载接口。
+- 攻击者通过修改 URL order_id=xxx，获取他人订单详情。
+
+### 3.4 垂直越权：普通用户调用管理员接口
+
+- 普通用户调用 /admin/deleteUser。
+- 若仅靠前端按钮控制权限，后端无校验，则直接越权成功。
+
+### 3.5 鉴权逻辑仅在网关，后端未鉴权
+
+- API Gateway / Nginx 配置了鉴权规则，但后端服务自身无鉴权。
+- 攻击者通过 SSRF / 内网跳板 直连后端，绕过网关调用接口。
+
+```
+# 外网访问被网关阻挡
+GET https://api.example.com/admin/deleteUser?id=123 -> 403 Forbidden
+
+# 内网直连绕过网关
+GET http://10.0.0.5:8080/admin/deleteUser?id=123   -> 200 OK
+```
+
+### 3.6 鉴权逻辑被编码/截断/大小写绕过
+
+- 仅拦截 /admin/，但攻击者用 /admin%2F、/Admin、/admin;.jsp 绕过。
+
+```java
+// Bad：基于 startsWith() 的字符串判断
+if (uri.startsWith("/admin")) {
+    checkAdmin();
+}
+// 绕过：双编码
+GET /admin%2fdeleteUser?id=1  -> 绕过鉴权
+```
+
+## 4. 漏洞修复方案
+
+### 4.1 【必须】所有权限校验在后端完成
+
+- 不依赖前端按钮或网关规则，后端每个接口都必须有鉴权逻辑。
+
+### 4.2 【必须】资源级/行级权限控制（user_id/tenant_id）
+
+- 在数据查询层面增加 user_id/tenant_id 条件，保证只能访问自己的数据。
+
+```python
+# Bad Code: 根据传入 ID 查询
+User findUser(Long id);
+```
+
+```python
+# Good Code: 限制为当前登录用户
+User findUserByIdAndTenant(Long id, Long tenantId);
+```
+
+### 4.3 【必须】敏感接口必须加角色/权限控制注解
+
+- Spring Security: @PreAuthorize("hasRole('ADMIN')")
+- Django: @permission_required("app.delete_user")
+
+### 4.4 【建议】使用统一的 RBAC/ABAC 框架
+
+- 统一鉴权框架，避免业务线各自实现，减少漏鉴权。
+
+### 4.5 【必须】后端服务自身必须做鉴权，不能仅依赖网关
+
+- 网关鉴权是 第一道防线，后端鉴权是 最后一道防线。
+
+### 4.6 【建议】服务间调用采用 mTLS / JWT / API Key
+
+- 即使是内网调用，也要有身份凭证，避免伪造请求。
+
+### 4.7 【必须】统一路径规范化再鉴权
+
+- URL 统一大小写、解码、normalize 后再匹配。
+
+```java
+// Good Code: Spring Security 推荐方式
+http.authorizeHttpRequests()
+    .requestMatchers("/admin/**").hasRole("ADMIN")
+    .anyRequest().authenticated();
+```
+
+### 4.8 【建议】敏感操作二次确认
+
+- 如转账、删号、权限变更，需要二次验证码/密码确认。

package/knowledge/skills/web-security-guide/references/auth-session.md

@@ -0,0 +1,99 @@
+# 认证和会话管理不当
+
+## 1. 漏洞原理
+
+- 认证和会话管理不当指应用程序在登录验证、身份令牌（如JWT、SessionID）、Cookie配置等关键身份凭据的生成、传输、验证过程中存在设计或实现缺陷，导致攻击者可以冒充合法用户或维持非法会话。
+
+## 2. 漏洞影响
+
+- 账户暴力破解：登录接口无限制尝试密码
+- Token猜解/重放：弱Token或无过期机制导致账号被劫持
+- 会话劫持：Cookie 被JS或中间人窃取
+- 权限穿越：身份伪造后访问其他用户数据或管理接口
+- 长时间控制：Token 永不过期、用户退出无效化
+
+## 3. 典型业务场景
+
+### 3.1 登录未限速或缺验证码（暴力破解）
+
+- 漏洞示例代码如下：
+
+```python
+# Flask 示例：无限尝试登录
+@app.route('/login', methods=['POST'])
+def login():
+    username = request.form['user']
+    password = request.form['pass']
+    if check_user(username, password):
+        return 'login ok'
+    else:
+        return 'fail'
+```
+
+### 3.2 Token 可预测或未过期（重放攻击）
+
+- 漏洞示例代码如下：
+
+```python
+# 使用时间戳或用户名作为token
+token = hashlib.md5(username.encode() + str(time.time()).encode()).hexdigest()
+```
+
+### 3.3 Cookie 未设置 HttpOnly / Secure / SameSite（被盗用）
+
+- 漏洞示例代码如下：
+
+```python
+# Flask 设置 cookie 时未加 HttpOnly / Secure
+resp.set_cookie('session_id', session_id)
+```
+
+- 修复建议：
+
+```python
+resp.set_cookie('session_id', session_id,
+    httponly=True,  # 防止JS读取
+    secure=True,    # 仅HTTPS传输
+    samesite='Strict')  # 防止跨站携带
+```
+
+### 3.4 JWT 签名绕过或私钥泄露
+
+- 使用不安全的算法，如 alg: none
+- JWT 密钥泄露、使用弱秘钥（如 test、123456）
+
+### 3.5 用户登出无效，旧会话仍可用
+
+- JWT/Session未绑定设备信息，登出后未销毁旧 token，攻击者可长期使用
+
+## 4. 漏洞修复方案
+
+### 4.1 【必须】使用强随机 Token + 签名验证机制
+
+- 使用 secrets、uuid4、os.urandom 生成随机Token
+- JWT等结构化Token需添加签名 + 加密 + 时效控制
+- 明确算法算法配置（HS256、RS256），禁用"none"
+
+### 4.2 【必须】Token 设置过期时间并支持吊销
+
+- Access Token 推荐有效期 ≤ 15分钟
+- Refresh Token 设置较长时间，并限制单设备有效
+- 可在 Redis 维护 blacklist、revoked 状态表
+
+### 4.3 【必须】配置 Cookie 安全属性
+
+- 开启HttpOnly：禁止 JS 读取 cookie
+- Secure：仅在 HTTPS 下传输
+- SameSite=Strict 阻止第三方携带 Cookie 发起请求
+
+### 4.4 【必须】登录限速 + 验证码策略
+
+- IP维度/账号维度做登录次数限制
+- 多次失败需冷却或触发验证码
+- 应记录登录日志并告警异常登录行为
+
+### 4.5 【建议】用户绑定多端设备与会话管理
+
+- 多终端登录记录中应显示设备、IP、登录时间
+- 后台可选择"踢出其他设备"、"只允许单端登录"
+- 所有 token 使用者身份变化时强制刷新

package/knowledge/skills/web-security-guide/references/csrf.md

@@ -0,0 +1,59 @@
+# 跨站请求伪造（CSRF）
+
+## 1. 漏洞原理
+
+- 跨站请求伪造（Cross-Site Request Forgery, CSRF），是指攻击者诱导已登录的用户，在不知情的情况下向受信任站点发起恶意请求，从而执行敏感操作。
+- 本质：应用只依赖 Cookie/Session 等隐式凭证鉴权，而未绑定用户意图（缺乏额外验证），导致用户在第三方页面访问时也能"自动带上凭证"。
+
+## 2. 漏洞影响
+
+- 用户账户被盗用：攻击者可伪造请求修改用户信息、邮箱、密码。
+- 金融类业务损失：伪造转账、支付、购买请求。
+- 权限维持与系统破坏：攻击者可在后台添加管理员、开启恶意配置。
+- 长期隐患：攻击可通过钓鱼站点、广告投放、论坛嵌入图片等途径批量触发。
+
+## 3. 典型业务场景
+
+### 3.1 用户已登录，访问恶意站点触发转账/改密
+
+- 攻击者在钓鱼网站放置隐藏表单或图片：
+
+```html
+<img src="https://bank.com/transfer?to=attacker&amount=1000">
+```
+
+- 如果银行网站仅依赖 Cookie 鉴权，用户已登录时就会直接完成转账。
+
+### 3.2 使用 GET 请求执行敏感操作
+
+- 系统用 GET 请求处理改密：
+
+```
+https://example.com/resetpwd?new=123456
+```
+
+- 攻击者只需诱导点击链接即可完成修改。
+
+### 3.3 未校验 Origin/Referer
+
+- 后端只依赖 Cookie 验证，未检查请求来源，导致任意第三方页面可发起敏感请求。
+
+## 4. 漏洞修复方案
+
+### 4.1 【必须】启用 CSRF Token / 双提交 Cookie
+
+- 后端生成随机 Token，绑定到用户会话，在表单或请求头中附带，后端验证一致性。
+- 双提交 Cookie 模式：前端 JS 写入 Cookie 和请求参数，后端校验两者一致。
+
+### 4.2 【必须】敏感操作使用 POST/PUT/DELETE
+
+- 禁止使用 GET 请求执行转账、改密、删除等操作。
+
+### 4.3 【必须】校验 Origin/Referer 请求头
+
+- 服务端必须验证请求来源域名与白名单匹配。
+- 对跨域请求强制使用 CORS 配置。
+
+### 4.4 【建议】关键操作需二次确认（验证码/密码输入）
+
+- 转账、改密等高风险操作要求再次输入验证码或密码，增加攻击难度。

package/knowledge/skills/web-security-guide/references/data-exposure.md

@@ -0,0 +1,108 @@
+# 敏感数据泄漏
+
+## 1. 漏洞原理
+
+- 敏感数据泄漏（Sensitive Data Exposure） 是指应用在传输、存储或处理过程中未正确保护敏感信息，导致攻击者能够直接获取或间接推测出这些数据。
+- 常见敏感信息包括：
+  - 用户身份凭据（用户名、密码、Token、Session ID、JWT）
+  - 个人身份信息（身份证号、手机号、邮箱、银行卡号）
+  - 系统敏感配置（数据库密码、API Key、私钥、证书）
+- 漏洞的本质是 缺乏加密、脱敏、访问控制或最小化原则。
+
+## 2. 漏洞影响
+
+- 账号接管：用户凭证或 Token 泄露 → 伪造请求控制账号。
+- 身份冒充：Session ID、JWT 泄露 → 跳过认证，直接操作业务。
+- 数据泄露：手机号、身份证号、银行卡号泄露 → 触发合规风险（GDPR/等保）。
+- 横向攻击：Redis/MySQL/消息队列口令泄露 → 攻击者可扩展为 RCE、数据篡改。
+
+## 3. 典型业务场景
+
+### 3.1 接口返回中包含敏感字段
+
+```python
+# Bad Code:
+return {
+    "username": user.username,
+    "email": user.email,
+    "password": user.password,
+    "id_card": user.id_card
+}
+```
+
+```python
+# Good Code:
+# 仅返回必要字段，并对敏感信息做脱敏处理
+return {
+    "username": user.username,
+    "email": user.email,
+    "id_card": mask_id_card(user.id_card)  # 仅显示部分
+}
+```
+
+### 3.2 配置文件中硬编码密钥 / Token
+
+```python
+# Bad Code:
+# 配置中硬编码敏感密钥
+DB_PASSWORD = "123456"
+SECRET_KEY = "myjwt-secret"
+```
+
+```python
+# Good Code:
+# 使用环境变量或安全配置中心（KMS、Vault）
+import os
+
+DB_PASSWORD = os.getenv("DB_PASSWORD")
+SECRET_KEY = os.getenv("JWT_SECRET")
+```
+
+### 3.3 未使用 HTTPS 或 TLS 加密
+
+- 请求用户登录或注册接口走 http，传输过程被中间人拦截。
+- 与 Redis、MySQL 交互不启用 SSL。
+
+```nginx
+# Bad Code:
+# Nginx 配置，未启用 HTTPS
+server {
+    listen 80;
+    server_name example.com;
+}
+```
+
+```nginx
+# Good Code:
+# 强制 HTTPS，启用 TLS1.2+
+server {
+    listen 443 ssl;
+    server_name example.com;
+
+    ssl_certificate /etc/ssl/cert.pem;
+    ssl_certificate_key /etc/ssl/key.pem;
+    ssl_protocols TLSv1.2 TLSv1.3;
+}
+```
+
+## 4. 漏洞修复方案
+
+### 4.1 【必须】接入自动化检测工具（如 CodeCC）
+
+- 对代码、配置文件、日志进行扫描，发现硬编码的密码、Token、私钥等敏感信息。
+
+### 4.2 【必须】禁止 DEBUG 模式上线
+
+- 生产环境关闭调试模式，避免异常栈和环境变量暴露。
+
+### 4.3 【必须】禁止明文 Cookie、未加密连接
+
+- Session Cookie 设置 Secure + HttpOnly，禁止 HTTP 明文传输。
+
+### 4.4 【必须】使用字段白名单，仅返回必要业务字段
+
+- 响应接口仅返回必要数据，避免冗余敏感字段泄露。
+
+### 4.5 【建议】所有用户相关请求强制 HTTPS
+
+- 对 Web/APP/小程序接口启用 TLS，全站 HTTPS。

package/knowledge/skills/web-security-guide/references/deserialization.md

@@ -0,0 +1,59 @@
+# 反序列化漏洞
+
+## 1. 漏洞原理
+
+- 反序列化漏洞是指应用程序在反序列化不可信数据时，攻击者通过构造恶意序列化对象，触发类的特殊方法（如构造器、readObject()、`__wakeup()` 等），最终执行任意代码或逻辑。
+- 本质：反序列化时，程序会自动实例化对象并调用其中的方法，攻击者利用可控输入触发危险 Gadget 链。
+
+## 2. 漏洞影响
+
+- 远程代码执行（RCE）：攻击者可执行系统命令，直接控制服务器。
+- 越权与逻辑绕过：绕过认证、加载恶意配置或篡改缓存。
+- 拒绝服务（DoS）：构造超大对象、循环引用导致内存耗尽。
+- 供应链攻击：利用第三方库（如 Commons-Collections）中的 Gadget 链触发漏洞。
+
+## 3. 典型业务场景
+
+### 3.1 Java 反序列化（Commons-Collections 链）
+
+- Java 原生 ObjectInputStream.readObject() 在加载 Commons-Collections、Spring 等常见库时，可能被攻击者构造链条利用，最终执行 Runtime.exec()。
+
+### 3.2 Python pickle.loads() 处理用户输入
+
+```python
+import pickle
+data = request.GET.get("data")
+obj = pickle.loads(data)  # 漏洞点：可控输入
+```
+
+- 攻击者可通过恶意 pickle 数据包执行任意代码。
+
+### 3.3 PHP unserialize() 外部数据可控
+
+```php
+$data = $_POST["data"];
+$obj = unserialize($data);  // 漏洞点：可控输入
+```
+
+- 如果项目中存在魔术方法 `__wakeup()` / `__destruct()`，攻击者可利用反序列化链实现命令执行或文件删除。
+
+## 4. 漏洞修复方案
+
+### 4.1 【必须】禁用不安全反序列化接口（pickle/unserialize）
+
+- 严禁对用户可控数据直接调用 pickle.loads()、unserialize()、ObjectInputStream.readObject()。
+
+### 4.2 【必须】使用 JSON/Protobuf 等安全格式
+
+- 替代不安全的二进制序列化方式，使用 JSON、Protobuf、MessagePack 等明确定义字段的安全数据交换格式。
+
+### 4.3 【必须】引入白名单类/安全库（Kryo、Jackson）
+
+- 仅允许反序列化可信类型（白名单）；使用支持安全模式的库，例如：
+- Jackson 启用 enableDefaultTyping(false)，避免自动反序列化任意类。
+- Kryo 提供类注册机制，限制可反序列化对象。
+
+### 4.4 【建议】反序列化数据前签名校验
+
+- 对序列化数据增加 HMAC/数字签名 校验，确保数据未被篡改。
+- 仅反序列化可信来源的数据，避免跨域或外部传输的直接反序列化。