十年后重做百度安全研发笔试题：核心考点与实战思路

2015年秋天我去考百度安全研发岗位的笔试，说实话，拿到卷子的前五分钟是有点蒙的——它和我预想的“漏洞利用大赏”完全不在一路。整张卷子没有一道题让你直接渗透某个靶场或者写个exp，反而全是“给你一段代码请找出问题”“这个场景请你设计一套安全方案”这类非常工程化的题目。后来我才反应过来，安全研发岗要的根本不是单纯的攻防手感，而是“你能不能把一个安全问题在代码和架构层面真正解决掉”。这份卷子放在今天回看，很多考点不仅没过时，反而成了现在安全研发岗面试题的原型。

如果你正准备走安全方向，或者已经在做安全开发、安全测试，想理解大厂安全团队招人时到底在考察什么，这篇文章应该能给你提供一个比较完整的视角。下面我会结合当年那场笔试的还原记忆，拆一下整张卷子的出题逻辑、核心考点，以及放到2025年的今天应该怎么重新答这些题。

1. 为什么一份2015年的安全研发笔试值得翻出来重做

1.1 安全研发岗和渗透测试岗的差别，卷子上一眼就能看出来

很多人一开始接触安全，想的都是“白帽子”“渗透测试”“漏洞挖掘”，觉得安全工程师就是整天找漏洞。但百度这类大厂的安全团队里，研发岗和测试/渗透岗是两条完全不同的线。研发岗要负责写扫描器、做安全组件、做风控系统、审计代码、设计安全架构。说白了，渗透岗是“发现问题的人”，研发岗是“解决问题并且防止问题再次出现的人”。

这份试卷非常鲜明地体现了这个分工。它不考你某个漏洞怎么打，而考你知不知道漏洞为什么存在、在代码层面怎么修、在架构层面怎么防。我记得有一道题给了两个函数，一个是用字符串拼接SQL，另一个是用了参数化查询，让你分析两者在安全性上的本质差异。这种题对纯攻击思路的人来说会很别扭，但对于真正做安全研发的人而言，这就是日常。

1.2 2015年前后的安全行业坐标

2015年这个时间点很特殊。移动互联网正是最热的时候，各类业务快速上线，安全基本是给业务“擦屁股”的。但头部大厂已经开始从“上线后再打补丁”转向“安全前置”。安全开发生命周期的概念在那两年被反复提及，代码审计、安全测试、威胁建模也开始成为安全团队的标配能力。

整个行业有一种“粗放建设转向精细化建设”的味道。安全研发岗位要解决的核心问题，不是去发现一个0day，而是如何让公司几十上百条产品线的代码在写出来的那一刻就尽量不带漏洞。所以这份笔试里大量题目都围绕着一个核心：你作为一个安全工程师，能不能把你对漏洞的理解转化成可落地的防护方案和编码规范。这一点在我后来的工作里反复被验证——安全研发最大的难点从来不是技术本身，而是如何在一个复杂业务系统里把安全机制嵌入得足够顺滑。

2. 整张卷子的题型分布与出题者的真实意图

2.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安全、云安全、供应链安全这些方向，笔试不一定直接考，但很可能出现在最后一道开放题里，考察你有没有持续学习行业动态。我当时的建议是：看到一个安全热词，先问自己三个问题——它解决什么问题？它攻击面在哪？它和经典安全模型有什么关系？只要能把这三个问题想清楚，就算遇到完全没见过的概念，你也能用底层逻辑撑起一个及格的答案。

这份笔试卷子到今天已经过去快十年，很多技术细节已经被框架和平台掩盖，但出题人想要的能力画像一点都没过时：扎实的原理理解、拿得出手的代码能力、能落地的工程方案。如果你能把这份卷子上的思维模式真正内化，不管以后是去大厂做安全研发，还是自己创业做安全产品，都会受益很久。