2015年秋天我去考百度安全研发岗位的笔试说实话拿到卷子的前五分钟是有点蒙的——它和我预想的“漏洞利用大赏”完全不在一路。整张卷子没有一道题让你直接渗透某个靶场或者写个exp反而全是“给你一段代码请找出问题”“这个场景请你设计一套安全方案”这类非常工程化的题目。后来我才反应过来安全研发岗要的根本不是单纯的攻防手感而是“你能不能把一个安全问题在代码和架构层面真正解决掉”。这份卷子放在今天回看很多考点不仅没过时反而成了现在安全研发岗面试题的原型。如果你正准备走安全方向或者已经在做安全开发、安全测试想理解大厂安全团队招人时到底在考察什么这篇文章应该能给你提供一个比较完整的视角。下面我会结合当年那场笔试的还原记忆拆一下整张卷子的出题逻辑、核心考点以及放到2025年的今天应该怎么重新答这些题。1. 为什么一份2015年的安全研发笔试值得翻出来重做1.1 安全研发岗和渗透测试岗的差别卷子上一眼就能看出来很多人一开始接触安全想的都是“白帽子”“渗透测试”“漏洞挖掘”觉得安全工程师就是整天找漏洞。但百度这类大厂的安全团队里研发岗和测试/渗透岗是两条完全不同的线。研发岗要负责写扫描器、做安全组件、做风控系统、审计代码、设计安全架构。说白了渗透岗是“发现问题的人”研发岗是“解决问题并且防止问题再次出现的人”。这份试卷非常鲜明地体现了这个分工。它不考你某个漏洞怎么打而考你知不知道漏洞为什么存在、在代码层面怎么修、在架构层面怎么防。我记得有一道题给了两个函数一个是用字符串拼接SQL另一个是用了参数化查询让你分析两者在安全性上的本质差异。这种题对纯攻击思路的人来说会很别扭但对于真正做安全研发的人而言这就是日常。1.2 2015年前后的安全行业坐标2015年这个时间点很特殊。移动互联网正是最热的时候各类业务快速上线安全基本是给业务“擦屁股”的。但头部大厂已经开始从“上线后再打补丁”转向“安全前置”。安全开发生命周期的概念在那两年被反复提及代码审计、安全测试、威胁建模也开始成为安全团队的标配能力。整个行业有一种“粗放建设转向精细化建设”的味道。安全研发岗位要解决的核心问题不是去发现一个0day而是如何让公司几十上百条产品线的代码在写出来的那一刻就尽量不带漏洞。所以这份笔试里大量题目都围绕着一个核心你作为一个安全工程师能不能把你对漏洞的理解转化成可落地的防护方案和编码规范。这一点在我后来的工作里反复被验证——安全研发最大的难点从来不是技术本身而是如何在一个复杂业务系统里把安全机制嵌入得足够顺滑。2. 整张卷子的题型分布与出题者的真实意图2.1 题型结构大致分为四块以我记忆里的还原整张卷子的结构大概是这样的题型大致题量考察重点选择题10道左右基础概念、协议、算法特性、常见漏洞成因简答题4到5道漏洞原理分析、安全机制设计思路代码审计2到3道从代码片段中找出漏洞并说明修复方案综合方案设计1道针对真实业务场景设计完整安全方案选择题里比较典型的包括TCP握手过程的序列号变化、HTTPS握手时证书的作用、MD5和SHA1的差异、常见端口对应的服务、XSS和CSRF的区别这类。这些题不深但覆盖面很广主要考察你有没有一个扎实的安全基础知识面。简答题就开始上强度了印象比较深的几类是“请说明SQL注入的原理并对比预编译和过滤两种防御方式的优劣”“为什么说Cookie不安全怎么设计一个相对安全的会话管理机制”“给你的业务设计一个登录认证流程需要考虑哪些安全点”。这些题目已经没有标准答案了完全是在看你的思维维度。代码审计题更直接给一段仿真的PHP或Java代码里面故意埋了典型漏洞让你找出来并说明修复方式。这种题最考验真实写码能力因为如果你平时不看代码只是背漏洞原理看到代码时很容易懵。最后那道综合方案设计我记得花了最多时间场景大概是一个新产品要上线里面有用户注册、支付、内容发布这些模块让你设计一套安全方案。这种题没有唯一答案但能清晰分辨出谁是真做过安全设计的谁只是背了一堆名词。2.2 透过题目看考察维度我自己复盘的时候把整张卷子的考点拉了一个维度表发现出题人其实只关心四件事原理是否透彻不是知道“SQL注入是一种攻击方式”而是能解释为什么拼接会产生注入参数化为什么能防防的边界在哪里。实战是否落地给的方案不能停在空中要能落在一个具体业务里。比如防XSS你光说“输出编码”不行你得说清楚在哪一层做编码、对谁编码、编码之后对功能有没有影响。工程化思维安全和业务永远有冲突你能不能找到可接受的平衡点。视野是否开阔题面里有些知识点是当时刚出来不久的东西比如HTTPS大规模普及下的中间人攻击场景如果你平时不跟踪新技术基本答不上来。所以这张卷子本质上不是考你会不会“搞安全”而是考你有没有“做安全研发”的思维方式。这一点后来我也用来面试别人只要问一个“请设计一个上传功能的安全方案”候选人对业务细节的追问程度基本就能判断出他有没有真实做过。3. 让我答得最纠结的几类题目3.1 Web漏洞原理题SQL注入、XSS和CSRF的“为什么”Web漏洞原理这块笔试里基本是必考的但考法不是让你背定义而是让你解释“为什么”。我现在还记得有道题问的是为什么即便很多程序已经做了输入过滤SQL注入依然经常发生这类问题比表面看起来要深得多。答案是过滤本质上是在和攻击者玩“猜规则”的游戏。你过滤了单引号攻击者可以用宽字节、注释符、内联注释你过滤了关键字攻击者可以用大小写混合、URL编码、等价函数。说白了基于黑名单的过滤永远有漏网之鱼。而参数化查询之所以被当成金标准在于它把SQL语句的结构和数据彻底分离了。数据库拿到的是一个“准备好了”的语句模板输入数据只是数据不再参与SQL语法解析。这就从根上消除了注入的可能性不管输入多刁钻它都只是一个参数而已。但这里有一个很容易被忽略的边界我当时也答得不够完整参数化查询只能防SQL语句的结构注入不能防存储过程内部的动态拼接也不能防因为动态表名、列名而被迫使用字符串拼接的场景。所以一个真正合格的安全研发需要理解预编译的边界知道在哪些场景下还得靠白名单和严格校验来兜底。XSS也是类似笔试里不会只让你说“XSS分存储型、反射型和DOM型”而会追问“为什么输出编码能防XSS在哪个环节编码”。本质上一句话XSS是浏览器把用户输入当代码执行了。输出编码做的事情就是告诉浏览器“这段内容你只能当数据显示不能当标签/脚本解析”。在服务端对输出上下文编码在客户端通过CSP限制脚本来源再配合HttpOnly保护Cookie这就是一套比较可靠的纵深防御。CSRF那道题我印象很深因为当时我写了一大堆核心其实就一句话CSRF的本质是浏览器会自动携带Cookie服务器无法区分这个请求是用户本人在页面上发起的还是第三方恶意页面偷偷发起的。防御思路自然围绕“让请求带上攻击者无法预知的信息”展开也就是CSRF Token机制或者校验同源请求头。现在再看SameSite Cookie已经把这个问题的默认解决往前推了一大步但2015年大家都在考虑怎么在服务端做校验。3.2 实战渗透思路题考的不是怎么打而是怎么判断还有一类题没有给真实靶场而是给了一段场景描述比如“一个金融类网站你觉得哪些接口最关键如果要优先做安全测试先测什么”。这是典型的实战思路题考察的是攻击面分析和优先级判断能力。我当时按这个思路答的第一先看认证和授权相关的接口登录、注册、找回密码、修改个人资料这些只要出问题就是水平越权或账号被盗第二看涉及资金、积分、订单等业务逻辑的接口重点测的是能不能篡改金额、能不能反向操作、能不能让订单状态异常第三才是看内容输入型的接口比如搜索、评论、上传这些位置容易出注入和XSS。现在的安全测试里大家越来越讲究攻击链而2015年的安全研发笔试已经有这个雏形了。比如面试官会更关心你能不能把一个低危问题串成高危利用链。上传一个图片马本身可能只是中危但如果配合一个解析漏洞让它执行再配合一个目录遍历漏洞找到路径就变成RCE了。当时我答得比较跳跃后来做实际项目才发现攻击链思维在研发设计阶段尤其重要——你要去思考的不是“单个点怎么防”而是“整条链路哪里可以被串联利用”。这里有一个我在实际工作里踩过的坑很多研发在处理“越权”问题的时候喜欢在前端隐藏按钮来“防”用户操作。但安全研发必须清楚前端只是体验层真正的权限校验永远只能在服务端做。用户完全可以绕过前端直接构造请求拿到他不该看到的数据。所以当你设计一个多租户系统或后台管理系统时每一个接口都要在服务端判断资源的归属权而不是相信前端传过来的用户ID或权限标识。3.3 代码审计题从危险函数到调用链代码审计题是整张卷子里最硬核的部分。网上的“java安全教程”“web安全”之类的内容刷再多如果没写过实际代码这部分的分数会比较惨。原因很简单代码审计是在代码的海洋里找“不合理”。没有大量的代码阅读训练看到一处正常的代码和一个可疑的调用脑子里很难快速拉响警报。我记得有一道题给的是一段用户登录的代码里面用了exec拼命令执行一个检查脚本。这道题一眼就能看到问题任何从外部输入透传到命令执行的位置都是危险的命令注入点攻击者可以用分号或管道符拼接自己的命令。修复方式也很明确不要用系统命令去做逻辑判断换成代码内实现如果确实需要调用外部命令绝对不能拼接用户可控参数得用参数数组方式传递并做白名单校验。另一道题考的是文件上传功能代码里直接用了前端传入的文件名来拼接保存路径。这个点考得不只是上传过滤还考了路径穿越。攻击者把文件名改成../../shell.php最后文件就可能被写到Web根目录之外或者覆盖其他文件。正确做法是服务端重新生成随机文件名按业务类型分目录保存并且对扩展名做白名单校验存储目录还要禁止脚本执行权限。代码审计题后面还延伸到一个我当时不太熟的点反序列化。2015年Java反序列化漏洞还没有大规模爆发但试卷里已经出现了一个小问题问“如果应用对反序列化的数据未做校验会有什么风险”。后来大家也都看到了Apache Commons Collections那条链子出来之后Java反序列化变成了安全研发必须高度关注的方向。现在做代码审计这块已经成为必查项。3.4 密码学与协议基础不考数学考选择试卷里很多密码学考核点其实不算难但非常实用。比如它会问存密码能不能用MD5为什么不能如果你只回答“MD5是可逆的”或“MD5容易被破解”其实没有答到点子上。准确的说法是MD5是哈希算法它本身是不可逆的但问题出在同一明文哈希结果固定攻击者可以预计算彩虹表MD5碰撞成本已经很低而且没有盐时相同密码的用户会得到相同的哈希值攻击者一旦拖库很容易批量还原弱口令。标准做法是使用带盐的慢哈希算法比如bcrypt、scrypt、PBKDF2或Argon2。它们引入随机盐使同一密码哈希结果不同又通过计算成本让暴力破解变得非常昂贵。这张考卷出现在2015年当时很多系统还在用MD5直接存用户密码说明“知道正确方案”和“在生产里落地正确方案”之间还有很长的路。还有一道关于随机数的题问“为什么安全场景不能用rand()这样的函数生成验证码或Token”。这个坑很典型伪随机数生成器如果种子可预测那么生成出来的随机序列也是可预测的。验证码、重置密码Token、CSRF Token这些机密值必须使用加密安全伪随机数生成器比如/dev/urandom、SecureRandom或os.urandom。当时我只知道“要用安全随机数”说不出具体的差异后来做风控系统时被线上问题狠狠教育了一次才真正理解这个选择的重量。4. 复盘当年的“标准答案”放在今天还成立吗4.1 十年没变的核心考点回到今天如果拿这份2015年的卷子去问现在的安全候选人我会说大部分核心考点的答案没有任何变化。SQL注入的基本原理没有变只是数据库和ORM框架让大部分人离裸露的SQL越来越远了但一旦使用jdbcTemplate拼接、MyBatis的${}、Elasticsearch的查询字符串漏洞依然会原样出现。XSS和CSRF的成因没有变防御思路也还是输出编码、CSP、Token、SameSite那一套。越权、文件上传、命令注入这些问题的根因在十年里一丝一毫都没有变过依然是安全笔试和法律规章里反复强调的高频风险。不变的原因也很简单这些漏洞没有一个是因为新技术出现而被消灭的它们只是被框架和平台默认安全机制压制了一旦有开发者绕开默认配置或者技术场景切换老漏洞马上会在新的包装下重新出现。所以安全研发的基本功永远是在底层原理上吃透而不是追着漏洞情报跑。4.2 被高速迭代的技术场景改写的“新考法”当然放到2025年有大量当时不在考卷上的内容已经成为安全研发的必修课。比如云原生安全。2015年大家还在纠结物理机和虚拟机现在容器、Kubernetes、服务网格已经成为业务标配。镜像安全、容器逃逸、集群权限配置错误、供应链投毒这些攻击面是全新的。安全研发要做的不只是一份静态代码审计报告而是在整个CI/CD流水线里嵌入镜像扫描、依赖检查、基础设施即代码的合规校验。再比如AI安全。现在各个大厂已经开始把AI安全加入笔试题考的是提示注入、模型数据泄露、RAG系统中的权限边界、生成内容的合规性以及AI Agent被越权调用工具的风险。这个方向在2015年的试卷里完全不存在。但如果你把它拉到原理层看其实底层很多东西依然是“输入不可信、边界要清晰、权限要最小化”这也印证了基本功扎实的人换一个战场依然能快速迁移。还有供应链安全。2015年大家用开源组件是随便引的现在一个不维护的依赖、一个仿冒的npm包就可能让整条产业链沦陷。安全研发现在必须把软件物料清单SBOM管理、依赖锁定、组件漏洞监控作为日常动作。我自己的感受是安全行业的技术风向标一直在变但出题人想看到的核心素质没有变。一个能讲清楚“为什么参数化查询能防注入”的人只要给他半年时间他也能把容器逃逸的原理讲清楚。反过来一个只会背“容器有逃逸风险”但不知道逃逸为什么可能发生的人换了技术栈就会彻底抓瞎。5. 给想走安全研发方向的你一点笔试实战建议5.1 先建立原理框架再刷题我见过很多准备安全方向的同学一上来就刷CVE复现、刷CTF题这是本末倒置。CTF和CVE是“术”能让你快速尝到攻击成功的快感但它们不能帮你建立系统性的安全研发思维。笔试和面试真正考察的是“道”是“你知道这里为什么有问题该怎么修”。我的建议是先花两周时间把安全基础体系打通认证与授权、输入校验、输出编码、加密与密钥管理、会话管理、访问控制、安全日志与监控。每一条都能说清原理、典型漏洞案例和标准修复方案再开始刷历年笔试题和CTF你会有一种“降维打击”的轻松感。5.2 答题时体现出工程判断力而不是背诵感简答题和方案设计题是拉开差距的地方。比如问“怎么防暴力破解”只写“加验证码、限制次数”只能算合格。但要拿高分你需要说清楚验证码放在哪个环节限制次数的粒度是按IP还是按账号还是按设备指纹限制之后的锁定策略会不会被攻击者用来批量锁定正常用户造成拒绝服务要不要引入风险评分和人工审核这种工程判断力不是刷题能刷出来的是多问自己“这个方案在真实业务里跑不跑得通”练出来的。我在笔试当时方案设计题写得太“通用”好像什么场景都能用但什么细节都没有落到具体业务上。后来面试官给我的反馈就是“方案完整但缺少权衡”。现在如果让我重新答我会主动写出“这个方案在性能上的代价是X在用户体验上的代价是Y因此我建议在注册流程用严格策略在低频操作上用宽松策略”这样的句子。5.3 代码题一定要动手写不能只看代码审计能力和写代码能力是强相关的很多人看漏洞分析文章觉得好简单一到自己上编译器就什么都在“想象中”。别偷懒把网上的安全演练靶场代码拉下来自己一行一行看再动手写出修复版。笔试里的代码题最高级的答法不是只指出“这里有问题”而是能给出修改后的片段并且解释为什么这样改不影响业务逻辑。在答题卡上写出带防御逻辑的代码远比写一百字说明更有说服力。5.4 关注安全领域的新名词但要落到原理AI安全、云安全、供应链安全这些方向笔试不一定直接考但很可能出现在最后一道开放题里考察你有没有持续学习行业动态。我当时的建议是看到一个安全热词先问自己三个问题——它解决什么问题它攻击面在哪它和经典安全模型有什么关系只要能把这三个问题想清楚就算遇到完全没见过的概念你也能用底层逻辑撑起一个及格的答案。这份笔试卷子到今天已经过去快十年很多技术细节已经被框架和平台掩盖但出题人想要的能力画像一点都没过时扎实的原理理解、拿得出手的代码能力、能落地的工程方案。如果你能把这份卷子上的思维模式真正内化不管以后是去大厂做安全研发还是自己创业做安全产品都会受益很久。