Question 1

拿到一个陌生的 Web 系统，你的漏洞挖掘思路是什么？

Accepted Answer

我先测绘再动手。第一步摸清资产与入口：子域、接口清单、上传点、第三方登录、后台路径，同时识别技术栈和框架版本——框架自带的防护决定了后面哪些方向值得投入。第二步画信任边界：哪些接口需要登录、哪些区分角色、越权面在哪。第三步按数据流找路径，把用户可控输入追到危险位置：拼 SQL、渲染 HTML、执行命令、反序列化、SSRF 的请求发起点。工具我用来做覆盖和回归，不用来替代思考——扫描器对越权和业务逻辑几乎无效，而这两类是现代系统里最常见的高危。我的经验是先花时间读接口和权限模型，再挑三五个最可疑的点手工深挖，产出比全量扫描高得多。

Question 2

SQL 注入和 XSS，你会怎么做纵深防御？

Accepted Answer

SQL 注入的根治只有一条：参数化查询（预编译），把数据和语句分开；表名列名这类无法参数化的位置用白名单枚举。过滤关键字是错误方向，绕过方式太多。兜底层我加数据库账号最小权限（业务账号不给 DDL、不给跨库）、慢查询与异常语法告警。XSS 我按输出上下文处理：HTML 文本、属性、URL、JS 上下文的转义规则不同，能用框架的自动转义就绝不手工拼；富文本必须用成熟白名单库做净化，不自己写正则。兜底层是 CSP 限制脚本源、Cookie 加 HttpOnly + SameSite 让 XSS 拿不到会话、敏感操作二次校验。WAF 我当作缓冲期手段——上线拦规则争取修复时间，但从不把它当作已修复。

Question 3

设计一套认证授权方案，你会怎么权衡 Session 与 JWT？

Accepted Answer

我按撤销需求选型。需要即时踢下线、管理会话列表的系统（后台、金融）我用服务端 Session 或有状态 token，撤销就是删记录，简单可靠。跨服务、跨域、需要无状态扩展的场景用 JWT，但要正视代价：签发即有效直到过期，撤销难。折中方案是 access token 短到 5-15 分钟、refresh token 有状态可撤销并绑定设备指纹，登出与风险事件时吊销 refresh 并把用户 ID 加短期黑名单。实现细节上我会锁定算法（拒绝 alg 为 none 或 HS/RS 混淆）、校验 aud 与 iss、不在 payload 放敏感信息。授权比认证更容易出事：垂直权限用集中式中间件按角色/策略判定，禁止前端隐藏菜单当权限；横向越权必须按资源归属校验——每次都用当前用户 ID 作为查询条件，而不是先按传入 ID 查再比对，后者太容易漏。

Question 4

线上密钥和凭据你怎么管理？

Accepted Answer

原则是密钥不落代码、不落聊天工具、不落日志。落地上用集中式密钥管理（云厂商 KMS/Secrets Manager 或 Vault），应用启动时按身份拉取，权限按最小化和环境隔离——测试环境永远拿不到生产凭据。仓库侧机制化拦截：pre-commit 与 CI 加密钥扫描，历史泄漏用轮换而不是删 commit 解决，因为删了也已经外泄。轮换我分两类：长期凭据设固定周期（比如 90 天）并尽量换成短期动态凭据，数据库和云资源优先用有效期几小时的临时凭据；服务间调用尽量用工作负载身份而不是静态 key。日志与报错要过滤，Authorization 头和 token 字段统一脱敏。泄漏应急的顺序是先吊销、再评估访问痕迹、然后轮换关联凭据、最后复盘补机制——顺序反了会给攻击者留窗口。

Question 5

安全左移具体怎么落地？研发不配合怎么办？

Accepted Answer

我把安全左移理解为三件事：卡点、供给、分级。卡点是把检查嵌进流水线——依赖漏洞扫描、SAST、密钥扫描、镜像扫描，结果直接出现在 PR 上而不是发周报；设计阶段对涉及认证、支付、数据导出的需求做轻量威胁建模，一页纸问四个问题：谁能访问、越权面在哪、失败时会怎样、日志够不够复盘。供给比要求更重要：与其要求各团队自己写加密和鉴权，不如提供已审计过的公共组件、脚手架默认开启安全头和参数化查询，让正确做法成为最省事的做法。研发不配合往往是因为噪音大和成本高：我把告警按可利用性和数据敏感度分级，高危阻断合并、中危限期修复、低危记录不打扰，同时提交可直接合并的修复 PR。这样做之后安全从「审计者」变成「供应方」，配合度自然上来了。

Question 6

发现正在进行的入侵，你的应急响应流程是什么？

Accepted Answer

我按取证、遏制、根除、恢复、复盘五步走，并且第一时间拉响应群、定指挥人、开时间线文档。取证先做：抓内存、保留日志与磁盘快照，防止后续处置毁掉证据；同时评估影响面——哪些主机、哪些数据、有没有横向移动痕迹。遏制看情况选强度：能隔离网络就隔离，核心业务不能停就先切断攻击者控制通道（封 C2 出口、吊销被盗凭据、强制会话失效），避免只杀单个进程让对方察觉后加速破坏。根除的重点是持久化：计划任务、启动项、SSH key、Web shell、被改的镜像与依赖包，凭据全部按泄漏处理轮换。恢复要从可信来源重建而不是原地清理，并保留监控加强观察期。复盘我要求产出两类结果：这次的根因链条，以及一条机制性改进（比如补上出网限制、加上文件完整性监控），否则同类事件会再来。

Question 7

一份好的渗透测试报告应该怎么写？

Accepted Answer

我按读者分层写。开头是一页管理层摘要：整体风险结论、高危数量与代表性风险、需要决策的资源投入，不放 payload。主体是逐个漏洞条目：位置、危害说明、分级理由（可利用难度、涉及数据敏感度、影响范围三项分别写清）、可直接照做的复现步骤（含请求样例与前置条件）、影响面确认（是否单点还是全站模板问题）、具体修复建议——不写「加强输入校验」这种空话，而写清改哪一行、用哪个 API、配置改成什么值，能给补丁片段就给。我还会加一节「已验证安全的部分」，说明测了哪些方向没发现问题，这样报告的边界清楚，不会被误读成全面安全认证。最后是修复优先级排序和复测约定。我的经验是修复率取决于研发能否照着做，所以复现和建议的可执行性比漏洞数量更重要。

Question 8

业务逻辑漏洞和越权，扫描器扫不出来，你怎么发现？

Accepted Answer

这类漏洞只能靠理解业务发现。我先把业务规则和状态机画出来：订单从创建到退款有哪些状态、每步谁能操作、金额和库存怎么变，然后专门找「规则假设」被绕过的路径。常见方向有四类：一是状态跳跃，直接调后置接口跳过支付或审核；二是数值边界，负数、超大值、小数精度、优惠叠加，比如退款金额大于支付金额；三是并发，同一张券或同一份库存并发请求造成超发，这类必须用真实并发脚本测，单请求看不出来；四是越权，我准备两个同级账号 A/B 和一个低权账号，把 A 的接口请求换上 B 的资源 ID 逐个重放，再用低权账号直调管理接口——很多系统只在前端隐藏入口。测试时我固定用双账号对照法，因为「用自己的 ID 能查到自己数据」永远是通过的，只有换 ID 才暴露问题。发现后我会判断是单点还是设计缺陷，设计缺陷要推动集中式权限判定而不是逐个打补丁。

安全工程师高频面试题：8 道必考题与作答要点