上个月面试一位有三年工作经验的候选人简历写得密密麻麻。我问他“拿到一个只给你域名的授权目标你会按什么顺序做信息收集每一步想拿到什么结果”他答得比较散子域名、端口、指纹这些词都蹦出来了但看不出他脑子里有一条清晰的路径。这个问题其实没有标准答案但面试官想听的是你怎样把“资产、边界、攻击面”三件事串成一条链。这篇是2026年“渗透测试面试题总结”系列的第12期我把近期在面试和内部考核里反复出现、又确实能拉开差距的题目整理在一起集中在“答案容易背、但答好很难”的地方。每个题目先给参考回答再拆解面试官的追问意图最后补一段我在实际项目里踩过的坑或验证过的经验。如果你准备面试建议不要直接背回答而是顺着追问思路自己推一遍。1. 信息收集题从“工具多”到“思路清”1.1 面试题给你一个域名如何尽快把资产收集完整这道题几乎每轮面试都会出现但大部分候选人只会报工具名子域名枚举、端口扫描、指纹识别……工具名谁都会说真正拉开差距的是顺序和理由。面试官心里的标准答案并不是“用某工具扫一遍”而是你在扫描前有没有建立一条“域名—IP—端口—技术栈—业务”的分层递进路径。我的参考回答是第一步做子域名枚举来源包括证书透明日志、历史DNS解析记录、第三方测绘库和常见字典爆破四个来源交叉验证避免单一路径漏掉资产。第二步做批量解析把每个子域名对应到IP同时识别CDN或云防护节点尝试通过证书信息、历史解析记录和主动探测手段找到真实源IP。第三步抓取目标门户页面和前端JS文件从里面提取接口路径、子域名、云存储地址、第三方密钥等新资产这一步经常能比单纯爆破多发现不少隐藏入口。第四步对最终确认的IP做全端口扫描拿到服务版本、Banner、标题和证书信息。最后把所有结果整理成一张资产表按组件、端口、技术栈、历史漏洞线索逐项标注攻击入口自然就浮出来了。追问时面试官会顺着一句“子域名很多先看哪些”来考你的优先级判断。我的经验是优先看开发测试环境、API网关、文档站点和第三方登录回调这类子域它们通常防护弱、业务逻辑复杂。有一次我在模拟项目X里正是从某个开发子域的后台入口切进去之后才在JS文件里挖到API网关地址整个测试路径一下子打开了。这个判断能体现你“在思考优先级”而不是把一筐工具倒出来。1.2 面试题端口扫描结果出来后你怎么判断哪些值得继续深挖我记得在一次内部考核里A同学把目标主机上百个开放端口全部扫完然后对着扫描报告发呆不知道从哪里下手。端口分析不需要把所有开放端口都测一遍关键是按业务价值排序否则就会把时间耗在大量无用端口上。我的参考回答是先看Web类端口包括80、443、8080、8443、8000等因为Web入口的利用面最大参数、接口、鉴权和业务逻辑问题都可能成为突破口。然后看中间件和数据库类端口比如3306、6379、9200、11211这些一旦存在弱口令或未授权访问通常可以直接拿到数据影响范围远大于Web漏洞。再往后是远程管理类端口如22、3389结合弱口令爆破、密码喷洒和已知漏洞验证来评估。最后才是其他业务端口比如消息队列、文件传输自定义端口等前面几条线都走不通时再看。端口常见服务第一反应优先级80/443/8080Web入口先看指纹、框架、历史漏洞高3306/6379/9200数据库与缓存测未授权访问、弱口令高22/3389远程管理看版本与弱口令风险中25/110/143邮件服务看用户枚举、开放中继中161/445/135网络管理/SMB/RPC结合内网渗透路径判断取决于环境这里想强调一个观点端口本身没有绝对危险关键看它背后的服务和暴露面。比如6379端口对外网开放和只在内网开放风险等级完全不同445端口在全域互通的环境里是横向移动的关键通道但在隔离网段里可能不值一提。面试官追问到这里通常就是想听你有没有“结合环境判断”的意识。1.3 面试题信息收集阶段哪些坑会让你前功尽弃这个问题是我自己加进来的因为实际项目里信息收集做得再全如果绕进坑里也会浪费大量时间。常见的坑有三个。第一个坑是CDN干扰。扫描结果里一堆CDN节点IP你以为自己扫到了目标其实只是打到了防护层。处理方法是先判断源站通过历史解析记录、邮件头信息、子域与主域解析差异来找真实IP同时留意证书信息里有没有源站特征。第二个坑是WAF拦截。还没开始正式测试就先被防护设备拦住了后面所有响应数据都会失真容易误判。我习惯在正式测试前先做一轮请求特征检查默认payload一上来就触发封禁说明当前链路不是正常测试链路需要调整来源或手法。第三个坑是资产归属错误。目标域名可能解析到公有云负载均衡或共享托管平台页面看起来像客户项目实际是另一个租户的服务这种情况下测出来的漏洞很容易误报。所以测试前要确认归属我只把确定属于授权范围的目标放进测试列表归属存疑的一律单独标注。这一节的结论就是信息收集不是工具用得越多越好而是要用一条清晰的判断链把结果收敛成几个真正值得打的入口后续的漏洞测试才会高效。2. Web漏洞高频题面试官想听“为什么”2.1 面试题SQL注入的分类那么多实际渗透中怎么快速判断类型这道题考察的是“原理理解”不是背分类。候选人如果只把联合查询、报错注入、布尔盲注、时间盲注的名字背一遍面试官基本不会满意因为这些分类只是表象真正的核心是“数据进入SQL语句的方式不同回显和判断方式就不同”。我的参考回答分五步。第一步拿到参数点先做基础探测在参数值后面加单引号或者加一个注释符看返回结果和正常请求有没有明显差异。第二步用逻辑判断确认注入比如在整型参数上构造“and 11”和“and 12”比较页面内容是否出现差异。第三步尝试联合查询通过“order by”判断列数如果输出点不在页面上就换成报错函数观察错误信息。第四步页面完全无回显时用布尔盲注通过页面真假差异逐位推断数据时间盲注留到实在没有其他手段时再用因为它效率最低而且受网络波动影响大。第五步根据数据库差异确认类型比如注释符、concat拼接方式、错误信息的特征。面试官在后面普遍会追WAF绕过特别是“基础payload被拦截时你会怎么办”。常见思路包括大小写混写、内联注释分割关键字、双写关键字、URL编码、HTTP参数污染、内容编码混淆等。但需要强调这些技巧都必须在授权范围内验证绕过WAF是测试的一部分前提是测试目标允许你做这种程度的验证。追问还有另一个高频点如何区分时间盲注的延迟是注入导致的还是网络本身不稳定我的做法是取基线先用正常请求测量多组响应时间再用固定条件的注入请求做重复测试控制变量后看延迟是否稳定复现。如果回答里带出“基线”“控制变量”这几个词面试官一般能感觉到你做的是真实测试而不是背书。2.2 面试题目标存在SSRF怎么做好验证和利用SSRF是近两年面试题里的常客难点在于很多候选人只知道“探测内网”说不清验证和利用的完整过程。面试官想听的是你对“服务端发起请求”这条链路的理解而不是只会背一两个IP地址。我的参考回答第一步是验证在自己的可控环境起一个监听服务把目标URL参数指向监听地址如果服务端收到回连请求就确认存在SSRF并能确认请求来自目标主机。第二步是内网探测把请求地址替换成常见内网网段地址观察响应内容、响应时间和错误信息差异逐步绘制目标的内网拓扑。第三步是针对云环境的判断如果目标运行在云上可以尝试访问云厂商的元数据服务地址读取实例元数据确认是否存在过度暴露的临时凭证但这一步必须在客户授权范围内进行不能把测试变成真实数据窃取。第四步如果是文件读取型SSRF可以试一下file协议读本地文件比如配置文件、密钥文件。第五步在服务端有请求白名单限制时考虑URL解析差异、DNS重绑定、重定向跳转和协议切换等方式做限制绕过。SSRF题目不要只背一个“读云元数据临时凭证”的结论面试官更想听到你能解释为什么这个地址可以被访问以及拿到临时凭证之后对攻击链意味着什么。理解到“服务端发起请求时没有对目标地址做约束”这个根因才算真正掌握了这类漏洞。2.3 面试题文件上传为什么经常测不透文件上传是另一个老牌高频题几乎每次面试都会聊到。常见误区是候选人一上来就说“上传个图片马再找包含点”但真实的文件上传利用链远没有这么简单。参考回答我会这样展开第一步先看前端校验逻辑是只校验扩展名、Content-Type还是同时校验文件内容再推断后端是否有二次校验。第二步针对黑名单场景尝试大小写混写、双扩展名、尾部加空格或点、特殊符号变形针对白名单场景上传合法格式后结合中间件解析路径特性寻找执行机会。第三步做内容层绕过把脚本内容嵌入一张合法图片中构造图片马再配合文件包含或服务端解析漏洞执行。第四步如果上传目录可以直连访问但不解析就观察是否能用条件竞争方式在文件被删除或重命名之前抢先包含执行。第五步上传成功之后不要急着高兴还要确认文件最终落盘位置、文件名是否被改写、访问时是否经过额外处理这三个点决定漏洞是否真正可利用。追问时面试官喜欢问“上传接口返回成功但文件无法访问可能是什么原因”。我的经验是先看响应包中的完整路径和文件名再看上传目录是否有独立域名或鉴权最后检查访问时是否经过CDN或静态资源处理。这道题如果回答里带上几个实际碰过的例子哪怕是模拟验证时的现象也比纯理论强得多。3. 内网渗透问题只会打点远远不够3.1 面试题拿到一台服务器之后十分钟内你要做哪些事这道题很能区分“打点型选手”和“内网型选手”。部分候选人一听到题目就报工具名什么“先跑密码抓取”“上扫描器扫内网”这在真实内网里是灾难级的操作既暴露行踪又容易打草惊蛇。我的习惯是第一确认当前身份。当前会话是本地普通用户还是管理员是单机环境还是域环境这个决定了后面所有操作的权限上限。第二看网络信息。有几个网卡、处于哪个网段、DNS后缀能不能解析出域控信息这些能快速判断当前主机在网络中的位置。第三看域关系。当前主机是否已加入域域控主机名能不能解析出来。第四收集凭据。内存中的哈希或明文、浏览器保存的口令、配置文件中的连接字符串、历史命令里的账号密码按优先级去翻。第五看进程和计划任务找出哪些服务以高权限运行哪些脚本文件带敏感参数这往往比直接爆破更高效。我想强调面试官真正想看的是你能否建立“先看身份再看目标最后找路径”的决策顺序。横向移动的本质是拿已有身份去访问原本没权限的资源所以第一步永远是搞清楚“我现在是谁、我能去哪”而不是上来就跑脚本。3.2 面试题横向移动的几种主流方式有什么区别、分别怎么选这道题考察面很宽因为攻击方式之间不是竞争关系而是互补关系。我把题目拆开讲先说结论横向移动没有万能的工具只有适应当前环境的路径。方式核心原理适用场景注意点哈希传递用NTLM哈希直接认证目标主机抓到了非明文哈希目标开启NTLM认证、账户有远程访问权限票据传递把Kerberos票据注入会话拿到了合法票据票据有效期和SPN范围决定可访问面WinRM远程管理通过5985/5986端口执行远程命令目标开启WinRM服务端口开放、账户有管理权限远程计划任务创建定时任务触发命令目标开放任务计划服务管理员权限、IPC连接可达追问点往往在“如果抓到的哈希是本地账户横向移动会受什么限制”。正确答案是本地账户哈希无法跨机器使用只能用于当前主机或本地账户体系域账户哈希则要受域策略中的NTLM认证限制不同域策略会让同一个哈希在不同主机上表现完全不同。候选人如果能答出“本地账户和域账户的区别”才说明不是只会跑工具。另一个容易忽视的细节横向移动之前一定要先确认目标主机允许哪些认证方式。不是所有机器都开了相同协议实际网络里经常遇到机器开了445却禁了NTLM或把WinRM端口映射到了非标准端口这时候就要换路径。面试官问到这一层核心是在看你遇到限制时会不会卡住。3.3 面试题Kerberoasting和AS-REP Roasting为什么反复被问这两个名词看起来高级其实核心原理只靠一个关键点Kerberos协议的一些阶段支持离线爆破。只要把这个点讲清楚面试官就会觉得你是真懂而不是只记攻击命令。参考回答可以这么拆AS-REP Roasting针对未开启预认证的域账户攻击者可以向域控请求该账户的AS-REP票据通过返回的加密数据离线破解出账户明文密码。Kerberoasting则是任何域用户都可以为指定SPN服务申请服务票据拿到服务票据后离线爆破服务账户密码因为这个票据由服务账户密码哈希加密。两者都不需要直接攻击域控也不需要管理员权限所以是普通域用户横向移动和提权的常见路径。面试官往下追问时大概率会问防御思路服务账户密码要足够随机和高强度定期检查SPN绑定并清理不再使用的服务账户开启Kerberos票据请求审计监控短时间内大量TGS请求的异常行为。这个回答能把“攻击原理”和“安全建设”连起来而不是只停留在攻击者的视角里。4. 报告、沟通、合规渗透测试里的软实力题4.1 面试题一份让开发心服口服的漏洞报告要包含哪些内容很多面试者以为这道题只是考文档排版其实考的是“你是否站在开发团队的角度考虑过问题”。开发团队最怕的不是安全问题而是报告写得无法复现、无法定位、无法整改。我的参考回答包括五个部分。第一部分是漏洞基本信息名称、等级、涉及URL或接口、影响范围、发现时间。第二部分是复现步骤这是报告的灵魂不能只写结论要把前提条件、操作路径、请求包和结果差异全部写清楚。第三部分是危害分析说明攻击者从利用到影响业务需要几步最坏情况是什么资产和数据会落到什么程度。第四部分是修复建议要具体到代码层或配置层比如“在参数进入查询前使用预编译语句”比“加强输入过滤”有用得多。第五部分是参考链接让开发可以查阅更完整的背景资料。我常常跟新人讲报告就是一个攻击脚本的交付物另一个安全工程师照着报告如果不能十分钟内复现这份报告就不合格。面试时如果能举出一次“报告复现失败”的改进经历比任何漂亮模板都加分因为这说明你真的在交付这件事上吃过亏、想过办法。4.2 面试题客户担心扫描影响业务你怎么回答这个问题在实际项目中出现的频率极高答得不好项目可能直接停摆。我的回答逻辑是“降低风险、明确边界、建立应急”三件事一起推进。先说明测试是有选择性的不是用默认配置对全网做高强度扫描对登录、写操作、删除类功能尽量做人工研判避免自动工具直接触发破坏性操作。再约定测试窗口放在业务低峰期扫描覆盖范围先排除核心交易链路机器。最后在正式测试前拉一次范围确认会与客户对齐资产清单、排除项、应急联系人和暂停机制把这些内容落到邮件确认里不能只靠口头。追问来了如果自动扫描还是把业务打崩了怎么办我的回答是第一时间停止所有测试动作按应急联系通道通报客户保留会话和请求日志之后复盘是哪个请求触发了故障修改检测规则并重新过一遍范围。这个追问其实不是考技术是考责任心和临场处理能力候选人如果只说“应该不会崩”基本就凉了。4.3 面试题发现0day漏洞后要不要立刻公开这道题考的是安全从业者的职业操守。答案的框架是负责任的披露流程而不是“发现漏洞就要公开”的冲动作法。我的参考回答是第一步确认漏洞影响范围和厂商。第二步通过厂商应急响应渠道提交完整报告附上可复现步骤和影响评估。第三步等待厂商进入修复周期根据修复进度协商公开时间如果厂商长期不响应可以提交到官方漏洞平台走协调流程。第四步公开时要控制细节尽量避免直接放可用的完整利用代码给受影响系统的管理员留出修复时间。面试官还会追问客户让你保密但漏洞又在公网暴露怎么平衡我的回答是先按客户要求保密但必须推动内部排期尽快修复修复完成前不扩散细节。安全测试的目的是降低风险不是制造舆论这个底线需要坚守。5. 容易被追问卡住的进阶问题5.1 面试题为什么Cookie设置HttpOnly和SameSite这么重要这题看似基础但追问空间很大。候选人如果只回答“防止XSS”马上就会被追问“HttpOnly防住所有XSS吗”所以参考回答要从攻击链路切入而不是只报属性名。HttpOnly属性的作用是让前端脚本无法通过document.cookie读取到Cookie所以即便页面存在存储型XSS攻击者至少无法直接窃取会话标识。SameSite属性则控制浏览器在跨站请求中是否携带Cookie设置严格模式或Lax模式能显著降低CSRF的触发面因为第三方站点发起的请求不会被带上认证状态。追问“HttpOnly能防住所有XSS”正确答案是不能。它只是防住了“读Cookie”这一步XSS仍然可以修改页面、调用接口、伪造操作。因此Cookie属性只是纵深防御中的一层真正要做的还是对输入输出做过滤、对敏感操作加二次校验。许多候选人在这一步把HttpOnly讲成“防XSS的工具”马上就会露馅。5.2 面试题JWT的安全隐患主要出现在哪些环节JWT是面试高频点原因很简单很多业务用JWT做会话管理但默认配置的安全基线很差面试官随便抽几个点都容易翻车。参考回答我会按四个环节拆一是签名算法环节服务端没有校验算法类型与预期一致时攻击者可以把RS256改成HS256再尝试用公钥内容作为对称密钥签名这是经典的算法混淆绕过。二是密钥强度环节HS256依赖一个对称密钥密钥太短或太常见就存在被离线爆破的风险。三是生命周期环节过期时间不校验、刷新令牌不过期都会放大泄露后的危害。四是使用环境环节通过URL参数传递JWT会让它落到日志里再配合日志泄露就可能被还原。面试官后面往往追问“修复时最优先做哪件事”。我的回答是算法白名单和密钥管理先把这两个问题解决再谈过期策略。判断一个候选人是不是真的调试过JWT看这个问题通常就能看出来因为只背过概念的人很难分清优先级。5.3 面试题怎么从日志完整还原一次攻击路径这是压轴题因为它能把“漏洞原理”和“安全运营”连起来。参考回答我习惯按时间线展开而不是一上来就报工具。第一步以安全告警时间为中心向前回溯一段时间找出攻击者的首次触达点。第二步整理来源IP和关联访问序列看是否包含目录扫描、参数探测、特殊payload等踩点特征。第三步检索URL和请求参数中的关键词把可疑请求一条条筛出来。第四步结合业务日志看账号行为一个普通账号突然大范围访问管理接口这个特征比IP维度更可靠。第五步把网络设备日志和服务端应用日志做关联还原完整的“探测—利用—权限落地—横移”链条。举个例子有一次模拟项目X收到SQL注入告警按IP封禁似乎就能交差但往前翻日志发现攻击者先访问了一个未授权的调试接口再结合同一IP的多次登录尝试记录才确认这是“先踩点、再爆破、后利用”的组合攻击。如果只看告警本身很容易漏掉早先的入口。面试官出这题通常希望听到你能以真实场景为例来证明自己不只会看单条告警。到这里这一期题目和参考回答就整理完了。最后提醒一句面试题永远不是靠背答案过的把每道题背后的原理推演清楚再用自己的话讲出来才是这份总结最该带走的东西。我自己在筛选题目时反复过滤的标准也只有一条这题能不能帮人把“知道”变成“理解”。如果读完有一两道题让你重新想了一遍自己的测试流程这期就算是写值了。