security · git:20260908.a2a662c · 2026-09-08 · sha256 82dba6885b0428a9

security git:20260908.a2a662cB

Immutable. This exact content is served forever at /api/v1/blob/82dba6885b0428a9.

---
name: security
description: 安全工程出题:Web 安全与漏洞原理、身份与权限、密码学应用、安全开发流程、渗透与应急响应、云与供应链安全。岗位或简历出现安全工程师、安全开发、渗透测试、应用安全、SDL、红蓝队、云安全时加载。
keywords: [安全, security, 安全工程师, 应用安全, appsec, 渗透测试, pentest, 红队, 应急响应, sdl, owasp, xss, 密码学, 云安全, 供应链安全]
layer: domain
---

## 岗位职责与考察重点

安全岗位分几条线:应用安全 / 安全开发(SDL、代码审计、安全组件建设)、渗透测试 / 红队(攻击视角找漏洞)、安全运营 / 蓝队 / 应急响应(检测、处置、溯源)、云安全与基础设施安全(IAM、网络、容器、供应链)。真实面试里最常被问的是"这个漏洞为什么会产生、怎么利用、怎么修才是根治而不是绕过",以及"发生入侵了你按什么顺序处置"。面试官最在意三件事:一是原理是否扎实——能否从协议或代码层面解释漏洞成因而不是背 OWASP Top 10 名词,二是有没有攻防对抗的真实经验(挖过什么、修过什么、误报怎么压),三是安全与业务的平衡感——知道什么该强推、什么该接受风险、怎么让研发愿意配合。

校招侧重原理与动手:常见 Web 漏洞的成因与 payload、HTTP 与浏览器安全机制(同源、cookie、CSP)、基础密码学概念、能读代码找问题、CTF 或 SRC 经历;社招侧重体系与判断:SDL 落地、漏洞治理与优先级、应急响应指挥、云上权限治理、供应链风险、安全工具的误报与覆盖率。国内一线厂与外企的安全面试近年都强调"给你一段代码或一份告警现场分析",以及对身份体系(OAuth/OIDC/零信任)和供应链攻击的理解。

## 主题

### 注入类漏洞:SQL、命令、模板
- 阶梯:注入的本质是什么 → 参数化查询为什么有效、ORM 也会注入的场景、盲注与带外 → 代码审计时怎么定位注入点(sink 与 source)、WAF 拦了但根因未修怎么推动 → 全量参数化的改造成本与 WAF 兜底的关系,遗留系统怎么排优先级
- 好题:一个 ORM 项目里 `order by` 字段来自前端参数并直接拼接。这算注入吗?怎么利用?为什么参数化解决不了这个位置?给出正确修法与在几百个类似接口里批量发现的思路。
- 危险信号:认为用了 ORM 就没有注入;修复靠过滤关键字;分不清报错注入与盲注的利用条件
- 期望信号:sink 分类(查询、排序、表名、命令行、模板)与各自修法;白名单映射;用 SAST 规则或 grep 批量找拼接点;WAF 只作兜底并知道绕过手段

### XSS、CSRF 与浏览器安全模型
- 阶梯:三种 XSS 的区别与 CSRF 的成因 → 同源策略、cookie 属性(HttpOnly/SameSite/Secure)、CSP 的作用与绕过、DOM XSS 的 sink → 前端框架已自动转义仍被打出 XSS、SameSite=Lax 下 CSRF 依然成立的场景,怎么查 → CSP 严格模式的落地阻力(内联脚本、第三方脚本)与分阶段推进
- 好题:React 应用被报存储型 XSS,团队说"React 会自动转义"。可能的漏洞位置有哪些(dangerouslySetInnerHTML、href javascript:、第三方组件、服务端渲染注入)?修复后怎么用 CSP 提供第二道防线,CSP 部署会遇到什么阻力?
- 危险信号:只会 `<script>alert(1)</script>`;认为 SameSite 解决所有 CSRF;不知道 CSP nonce 与 strict-dynamic
- 期望信号:按 sink 分析而非按 payload;CSRF token 与 SameSite 的组合;CSP report-only 先跑再收紧;对 postMessage、iframe、点击劫持有认识

### SSRF、文件与反序列化
- 阶梯:SSRF 为什么危险 → 云元数据服务、内网探测、协议走私、DNS 重绑定 → URL 校验被绕过(重定向、IPv6、进制混淆)、文件上传的多重绕过、反序列化 gadget 链,怎么防 → 出网代理统一收口的成本,反序列化白名单与替换序列化格式的取舍
- 好题:一个"根据 URL 抓取网页预览"的功能,你会怎么攻击它?列出至少五种校验绕过方式。防御方案里哪些是必须的(解析后校验、禁止重定向跟随、出网代理、元数据服务加固)?
- 危险信号:SSRF 防御只做黑名单 IP;文件上传只看扩展名;反序列化只知道"Java 有问题"
- 期望信号:解析 IP 后再校验并禁重定向;IMDSv2 或元数据防护;上传文件重命名、存储隔离、内容检测;反序列化替换为 JSON 或强类型白名单

### 身份认证与会话安全
- 阶梯:认证与授权的区别 → 密码存储(bcrypt/argon2、加盐)、MFA、会话固定、JWT 的常见错误(alg none、密钥弱、无法撤销)→ 登录接口被撞库、验证码被绕过、token 泄露后怎么止损与溯源 → 无密码、Passkey 的推进阻力,风控与用户体验的平衡
- 好题:审计一个 JWT 实现:密钥硬编码、alg 可选、无过期、用 localStorage 存。请按严重程度排序、说明各自的攻击方式,以及修完后"强制下线"怎么实现。
- 危险信号:密码用 MD5 加盐就觉得够了;不知道 JWT 的 alg 混淆;限流靠 IP 一个维度
- 期望信号:慢哈希与参数选择;JWT 固定算法与短期 + refresh 轮换;设备/账号/IP 多维限流与风险评分;会话撤销的实现路径

### OAuth2 / OIDC 与授权模型
- 阶梯:OAuth2 各授权模式适用场景 → 授权码 + PKCE 的必要性、state 防 CSRF、redirect_uri 严格匹配、ID token 与 access token 的区别 → 开放平台被报"账号劫持",可能出在 redirect_uri 宽松匹配、token 泄露在 referer、隐式模式,怎么查 → RBAC/ABAC/ReBAC 的选型,集中授权服务与分散判断的取舍,越权漏洞的系统性治理
- 好题:你们的 OAuth 登录 redirect_uri 只校验域名前缀,安全研究员据此劫持了账号。请还原攻击链,给出修复与全平台自查方案,并说明为什么隐式模式应该废弃。
- 危险信号:分不清授权码与隐式模式;state 参数不知道干什么;越权靠"前端不显示按钮"
- 期望信号:PKCE 与精确匹配;token 不落 URL;数据访问层强制归属校验(IDOR 治理);对细粒度授权系统(策略引擎)有认识

### 密码学应用与密钥管理
- 阶梯:对称、非对称、哈希、签名分别干什么 → AES 模式选择(GCM 与 CBC 的差异、IV/nonce 复用的后果)、TLS 握手与证书链、HMAC 与签名验签 → 自研加密方案被绕过、密钥泄露后轮换困难、证书过期导致全站故障,怎么处理 → 密钥管理系统(KMS/HSM)的引入成本,端到端加密与业务功能(搜索、风控)的冲突
- 好题:团队自己实现了"AES-CBC 加密 + 直接拼接 MD5 校验"的接口签名方案。有什么问题?padding oracle 和长度扩展攻击分别怎么打?给出正确方案与密钥轮换设计。
- 危险信号:自己发明加密算法;ECB 模式;nonce 固定;密钥写在配置文件里提交
- 期望信号:AEAD 优先;HMAC 而非裸哈希;密钥分层(KEK/DEK)与轮换;证书自动化与到期告警;知道什么不该自己实现

### 安全开发流程(SDL)与代码审计
- 阶梯:SDL 包含哪些环节 → 威胁建模、安全需求、SAST/DAST/SCA/IAST 的覆盖与局限、安全门禁 → 扫描工具误报率高研发不看、漏洞修复率上不去、安全成为发布瓶颈,怎么改 → 安全左移的投入产出,哪些环节自动化、哪些必须人工,安全组件化替代培训
- 好题:SAST 每次扫出上千条告警,研发直接忽略。给出治理方案:规则裁剪、分级、增量扫描、误报反馈、门禁策略各怎么做?怎么衡量 SDL 是否真的降低了线上漏洞?
- 危险信号:SDL 就是"上线前扫一遍";不知道 SAST 与 DAST 各自漏什么;审计只靠工具
- 期望信号:威胁建模从数据流与信任边界入手;工具分层与增量门禁;提供安全 SDK(统一鉴权、加密、参数校验)替代逐项修复;用漏洞逃逸率与修复时长衡量

### 渗透测试方法论
- 阶梯:渗透与扫描的区别 → 信息收集、攻击面梳理、漏洞验证、权限提升、横向移动的流程 → 拿到一个 Web shell 后怎么在不破坏业务的前提下证明危害、内网横向的常见路径(凭据、服务、信任关系)→ 授权边界与法律风险,报告怎么写才能让研发修、红蓝对抗的目标设定
- 好题:授权对一个企业的外网资产做渗透,你的完整流程是什么?拿到一个低权限内网入口后,横向移动的三种常见路径与各自的检测点是什么?报告里怎么呈现让业务方愿意优先修?
- 危险信号:只会跑扫描器;不知道授权范围;提权只知道"找 exp"
- 期望信号:攻击面与资产梳理优先;利用链条完整且可复现;横向移动的凭据窃取、服务滥用、配置错误路径;报告按风险与修复成本排序

### 安全运营、检测与应急响应
- 阶梯:入侵检测看什么信号 → 日志采集与关联、EDR/HIDS/NIDS 的分工、检测规则与 ATT&CK 映射 → 告警"疑似 webshell"来了,怎么在半小时内判断真伪、影响面、是否隔离;误报太多分析师疲劳怎么治 → 隔离止损与业务连续性的冲突,溯源投入的边界,复盘怎么转化为检测能力
- 好题:凌晨收到告警:某生产机出现异常外连与新建计划任务。请给出前一小时的处置步骤(确认、隔离、取证、溯源、通报)、每步的判断依据,以及怎么防止取证破坏。
- 危险信号:第一步就重装系统;不知道要保留内存与日志;没有通报与升级机制
- 期望信号:先确认再隔离,隔离方式尽量保留现场;取证顺序按易失性;用时间线关联登录、进程、网络;产出 IOC 与检测规则

### 云安全与 IAM
- 阶梯:云上安全责任共担模型 → IAM 最小权限、临时凭据、角色假设、存储桶与安全组配置错误 → AK 泄露到 GitHub 后攻击者做了什么、怎么在几分钟内止损、事后怎么审计影响 → 集中权限治理的推进阻力,多账号架构与安全基线自动化的成本
- 好题:一个长期有效的云 AK 被提交到公开仓库,两小时后发现。你按什么顺序处理?怎么用审计日志还原攻击者做了什么?长期上怎么消灭长期 AK?
- 危险信号:AK 直接写代码里;安全组 0.0.0.0/0;不知道 STS/角色假设
- 期望信号:立即禁用而非删除并保留审计;审计日志查异常 API 调用;转向角色与临时凭据;配置基线扫描(CSPM)持续检查

### 容器与基础设施安全
- 阶梯:容器逃逸的常见途径 → 特权容器、hostPath、能力集、镜像漏洞、K8s RBAC 与准入控制 → 集群内某 Pod 被入侵后攻击者能走多远(ServiceAccount token、元数据、etcd)、怎么限制 → 运行时检测(Falco 类)的噪音与覆盖,镜像签名与准入策略的推进成本
- 好题:一个应用 Pod 被 RCE,它用的是 default ServiceAccount 且集群 RBAC 宽松。攻击者的横向路径有哪些?给出分层加固方案(Pod 安全标准、RBAC、网络策略、运行时检测)并说明优先级。
- 危险信号:认为容器天然隔离;不知道 ServiceAccount token 自动挂载;镜像不扫描
- 期望信号:最小能力集与非 root;禁用自动挂载 token;NetworkPolicy 默认拒绝;镜像签名与准入校验;运行时行为基线

### 供应链安全
- 阶梯:供应链攻击是什么 → 依赖投毒、typosquatting、构建系统入侵、SBOM 与签名 → 一个深层依赖被爆高危漏洞,怎么在上千个仓库里找影响面并判断可利用性;CI 密钥被窃取怎么止损 → 依赖锁定与更新速度的矛盾,私有镜像源与内部代理的治理成本
- 好题:某广泛使用的日志库爆出 RCE。你怎么在两小时内知道公司哪些服务受影响、是否可被利用、先修哪些?长期上怎么建立依赖资产台账与快速响应机制?
- 危险信号:依赖不锁版本;不知道 SBOM;CI 里的密钥权限过大
- 期望信号:SCA 与 SBOM 集中台账;可达性分析区分"引入"与"可利用";私有源与镜像审批;构建产物签名与来源验证

### 安全治理与业务沟通
- 阶梯:安全部门和研发的常见矛盾 → 漏洞分级标准、SLA、豁免流程、安全评审前置 → 高危漏洞业务方以"影响上线"为由拖延、安全需求被砍,怎么推动 → 风险接受的决策机制与责任归属,安全投入怎么向管理层量化汇报
- 好题:你发现一个高危越权漏洞,业务方说修复要两周且影响大促上线。你怎么评估真实风险、给出临时缓解、推动决策并留下责任记录?
- 危险信号:安全一票否决或完全妥协两个极端;没有分级标准;风险接受口头进行
- 期望信号:按可利用性与影响量化;临时缓解(WAF 规则、功能开关、监控加强);风险接受书面签字;事后跟踪修复

## 好题 / 坏题对比

- 坏:OWASP Top 10 有哪些?
- 好:React 应用被打出存储型 XSS,团队说"框架自动转义"。可能的漏洞位置有哪些?修复后怎么用 CSP 做第二道防线?CSP 上线会遇到什么阻力、怎么分阶段推?

- 坏:说说 OAuth2 的授权码模式。
- 好:你们的 OAuth 登录 redirect_uri 只校验域名前缀,研究员据此劫持了账号。还原攻击链、给出修复与全平台自查方法,并解释为什么隐式模式应废弃、PKCE 解决了什么。

- 坏:应急响应的流程是什么?
- 好:凌晨告警某生产机异常外连并新建计划任务,给出前一小时的处置步骤与每步判断依据,怎么隔离才不破坏取证?溯源需要哪些日志?事后怎么把这次经验变成检测规则?

## 项目结合钩子

- 简历出现 SRC / CTF / 漏洞挖掘 → 追最有代表性的一个漏洞:怎么发现、利用链、厂商怎么修的、你觉得根治方案是什么
- 简历出现 SDL / 安全左移建设 → 追覆盖了多少仓库、工具误报率、漏洞修复率与时长变化、研发配合度怎么解决
- 简历出现渗透测试项目 → 追授权范围、最深打到哪、横向路径、报告里最难推动修复的一条
- 简历出现应急响应 / 安全运营 → 追处理过的最严重事件时间线、日均告警量与误报率、溯源到什么程度、产出了什么检测规则
- 简历出现 WAF / 安全网关建设 → 追规则数、误拦率、绕过案例、性能开销、与根治修复的关系
- 简历出现云安全 / IAM 治理 → 追账号数与权限模型、长期 AK 消灭进度、CSPM 发现的最典型配置错误
- 简历出现代码审计 → 追审计方法(工具 + 人工比例)、发现的最隐蔽漏洞、sink/source 怎么梳理
- 简历出现供应链 / SBOM → 追依赖台账覆盖率、上次高危依赖爆发时响应时长、可达性分析有没有做

## 出题原则

- 每个漏洞必须追到原理层与根治层:候选人说出 payload 后追"为什么会有这个漏洞、修法为什么有效、还有什么绕过";只会背名词与工具名的标记为危险信号。
- 攻防经历必问且要可验证:挖过的漏洞要能讲利用链,处置过的事件要能讲时间线,说不出细节的当作没做过。
- 安全与业务的平衡必考:让候选人在"高危但影响上线"的场景里做决策,只会一票否决或完全妥协的都是不成熟的表现。
- 不考漏洞编号与工具版本的时效性,考的是成因分析、分层防御与推动落地的能力。