校招安全岗笔试没那么玄乎大部分题目其实是把大学四年零散的知识点串起来考。我把自己当年整理的一份“美丽联合2018校招信息安全开发工程师笔试试卷”的复盘笔记翻了出来结合后来做面试官、带新人的经验重新梳理了一遍今天一次性把里面的考点、解题思路和背后的坑都讲清楚。无论你是正在准备校招的应届生还是半路转行想做安全开发的朋友这份拆解应该都能帮你少走不少弯路。这份试卷覆盖的面很典型Web安全基础、密码学应用、漏洞原理与利用、网络协议分析、基础开发能力。难度大概在“科班学过、但没实战过也能及格”的水平但想拿高分光会背书不行得有真正的代码功底和排查思路。下面我们一块一块说。1. 试卷整体结构与命题逻辑拿到卷子先别急着做题我习惯先看一遍题目分布判断出题人的侧重点。这份试卷大致分为五个板块Web安全与漏洞分析、密码学基础、网络协议、编程与算法、综合场景题。每个板块的分值比重并不均匀Web安全明显是重头戏这符合“信息安全开发工程师”这个岗位的定位——既要懂攻更要懂防还要能写代码实现防御方案。从命题逻辑上看出题人有三个明显意图。第一个是考察基础是否扎实比如 SQL 注入的绕过方式、XSS 的几种类型区分这些是安全开发的底线知识。第二个是考察实战思维比如给一段代码让你找出漏洞并修复这比单纯问“什么是 CSRF”要难得多因为它要求你同时具备代码审计能力和修复方案的落地能力。第三个是考察知识面的广度密码学、网络协议、操作系统都有涉及毕竟安全开发工程师在日常工作中要跟各种系统打交道知识面太窄很容易漏掉风险点。另外我注意到这套试卷很注重“原理实践”的结合。比如密码学部分不是只让背算法名字而是给定场景让你选合适的加密方案还要说明为什么。这类题目其实就是实际工作的缩影——你不可能所有算法都精通但你必须知道在什么场景下选什么工具。1.1 岗位能力模型与考察重点“信息安全开发工程师”这个岗位名称已经说明了要求本质是开发岗位但开发的对象是安全能力。所以试卷里编程题和漏洞分析题是交织在一起的比如让你实现一个简单的登录接口同时要考虑 SQL 注入、暴力破解、会话固定等安全问题或者给你一段有漏洞的代码让你在修复的同时保证业务功能不变。这种出题方式对纯安全研究型选手不太友好因为只懂攻击不懂修复拿不到分对纯业务开发选手同样不友好因为代码写得再漂亮安全漏洞一抓一把也是白搭。我的感受是这份试卷想筛选的是那种“能写一手干净代码同时脑子里时刻有攻防意识”的工程师。还有一个容易被忽略的点试卷里有些题目看起来是考知识点实际上是在考察你的排查思路。比如给你一份日志让你定位一次攻击行为这类题没有标准答案但你的分析路径是否合理、能否从蛛丝马迹中还原攻击链面试官一眼就能看出来。这种能力不是靠刷题能练出来的需要平时多读真实攻击案例、多做日志分析。2. Web安全核心考点拆解Web安全部分占了整张试卷将近三分之一的分值题目类型也比较多样从选择题到代码审计都有。我把其中比较有代表性的几类题目单独拿出来拆一下这些考点放到今天依然没有过时照样是面试高频题。2.1 SQL注入的一线实战细节试卷里有一道典型的 SQL 注入题目给了一段拼接 SQL 的登录代码问如何绕过登录、如何修复。代码大概是这样的$sql SELECT * FROM users WHERE name{$username} AND pass{$password};第一问很简单用万能密码 OR 11就能绕过这是几乎所有安全科普文章都会提到的点。但第二问“如何修复”才是拉开差距的地方。我看到很多同学的答案只写了“用预处理”这当然没错但缺乏细节。我建议的答案结构是这样首选方案使用 PDO 预处理 参数绑定。核心逻辑是 SQL 语句结构预先编译用户输入只作为参数值传递数据库不会把输入内容当作 SQL 指令执行。代码实例如下$stmt $pdo-prepare(SELECT * FROM users WHERE name ? AND pass ?); $stmt-execute([$username, $password]);辅助方案对输入做白名单校验。比如用户名只允许字母、数字和下划线用正则表达式过滤掉其他字符。但要注意白名单校验是纵深防御的一环不能替代预处理作为唯一防线。其他加固措施最小化数据库账号权限Web应用不使用 DBA 权限连接数据库关闭错误信息回显防止攻击者通过报错信息获取表结构。另外一个值得注意的坑是很多人以为过滤了单引号就万事大吉但实际上宽字节注入、二次注入、order by 注入等变种都能绕过简单的过滤。宽字节注入在 GBK 编码下尤为常见攻击者通过%bf%27这类编码让转义函数失效。所以我一向强调过滤函数只能作为辅助预处理的地位不可动摇。2.2 XSS的类型区分与利用链路XSS 的题目在试卷中主要是给三段代码分别对应反射型、存储型、DOM 型让你写出区别和对应的防御方案。这道题表面上是概念题实际上考察的是你对浏览器安全模型的深入理解。反射型 XSS 最容易理解恶意脚本在请求 URL 中服务端直接拼接进 HTML 返回。它的特点是一次性的攻击者需要诱导受害者点击构造好的链接。存储型 XSS 更危险恶意脚本被持久化存储在服务器数据库中所有访问该页面的用户都会中招典型的场景是评论区、用户昵称等。DOM 型 XSS 则不太一样它不经过服务端纯粹是前端 JavaScript 把不可信内容插入到了 DOM 中比如document.getElementById(user).innerHTML location.hash.substring(1);这种漏洞在纯前端项目里非常常见也是很多同学容易忽略的盲区。防御方案要分场景说。对于反射型和存储型核心是输出编码在 HTML 上下文中转义、、、、在 JavaScript 上下文中需要做 Unicode 转义在 URL 属性中要做 URL 编码。不同场景的编码规则不同混用就会出问题。对于 DOM 型 XSS核心是避免使用innerHTML、document.write这类危险函数优先使用textContent或者安全的 DOM 操作 API。我还想多说一句XSS 的利用链路经常被校招生忽视。一道进阶题问“存储型 XSS 除了弹窗还能干什么”大多数人的答案是盗 Cookie但更完整的回答应该包括结合 CSRF 漏洞修改用户资料、构造钓鱼页面、内网探测、结合浏览器漏洞实现 RCE。理解了利用链路你才真正理解为什么 XSS 被 OWASP 列为最普遍的漏洞之一。2.3 CSRF与SSRF的逻辑对比试卷里有一道对比题要求说明 CSRF 和 SSRF 的相同点与不同点。这两个漏洞名字很像但攻击链路完全不同很多同学容易混淆。CSRF跨站请求伪造的核心是利用了浏览器的 Cookie 自动携带机制。用户在登录状态下访问攻击者构造的恶意页面该页面偷偷向目标网站发送请求因为浏览器会自动带上用户的 Cookie服务端无法区分这个请求是否为用户本人发起的。经典的修复方案是加 Token 校验、二次确认弹窗、SameSite Cookie 属性、校验 Referer。SSRF服务端请求伪造则是利用服务端的请求功能让服务器去访问攻击者指定的内网地址。比如某个功能需要从远程服务器拉取图片攻击者把 URL 改成http://127.0.0.1:6379/就可能探测到内网中的 Redis 服务。SSRF 的防御要从协议白名单、IP 地址黑名单禁用回环地址和私网地址、Nginx 层控制内网访问入口、限制服务端请求的重定向行为等几个维度同时发力。这两个漏洞虽然不同但有一个共同点都是因为对请求的来源或目标缺乏严格校验。这也是安全开发中一个非常核心的思想——不要默认信任任何输入包括请求中的来源信息和自定义的 URL 参数。3. 密码学考点与应用场景分析密码学在试卷中占比不大但每一分都是送分题丢了很可惜。这部分考察的重点不是让你徒手实现 RSA而是考察你对常见加密算法的特征、适用场景和安全等级的掌握程度。3.1 对称加密与非对称加密的选择试卷中的一道典型题目给出四种应用场景分别是大数据量文件加密、密钥分发、数字签名、Web通信握手要求选择合适的加密算法并说明原因。正确答案的核心逻辑是对称加密效率高适合加密大量数据密钥分发是难题非对称加密安全但计算开销大适合加密少量关键数据如对称密钥、数字签名、密钥协商。所以实际系统中几乎清一色用混合加密方案先用非对称加密安全地协商出对称密钥再用对称密钥加密实际数据。HTTPS 的 TLS 握手就是这么干的用 ECDHE 或 RSA 做密钥协商用 AES 加密应用数据。还有一类题目是给出一段加密过程的伪代码让你判断哪里有问题。常见陷阱包括使用 ECB 模式的 AES这种模式明文相同的分组会得到相同的密文会暴露明文统计规律应该用 CBC 或 GCM使用不随机的 IVIV 必须随机且每次不同签名时先加密后签名导致的安全问题。这些细节在课本上都是一句话带过但在实际工程里却是漏洞的高发区。3.2 哈希算法的正确使用方式哈希算法部分有一道很经典的题目给定用户密码存储方案让你指出问题并优化。原方案是直接对MD5(password)存库。这题的错误点太明显了MD5 速度太快GPU 每秒可以算几十亿次配合彩虹表弱密码基本秒破。正确的存储方案应该使用专门的密码哈希算法比如 bcrypt、scrypt、Argon2。这些算法的一个共同特征是计算速度可以调节故意设计得“慢”让每一次破解尝试都付出高昂的算力代价。以 bcrypt 为例它的 cost factor 每增加 1计算时间翻倍我现在一般建议 cost 至少设为 10 或 12。另一个容易忽略的考点是“哈希不是加密”两者有本质区别。哈希是不可逆的单向函数加密是可逆的变换做题时如果把这两个概念混用会被扣掉不少分。还有盐salt的问题盐要随机、每用户不同、长度足够至少16字节才能有效抵御彩虹表和预计算攻击。3.3 数字签名与证书体系试卷在这一块考得比较浅主要是问数字签名的作用和 HTTPS 证书的信任链。数字签名的作用有三点完整性、认证性、不可否认性。签名方用私钥签名验证方用公钥验证由于私钥只有签名方持有所以可以证明消息的来源。涉及到 HTTPS 证书信任链的题目更有意思它会让你描述从浏览器到服务器证书的验证过程。完整的过程是服务器返回证书链浏览器从站点证书开始逐级向上验证签名的有效性一直到内置的根证书。如果中间某一级证书过期、被吊销或者签发机构不受信任浏览器就会给出安全警告。这道题背后的目的是让你理解 PKI公钥基础设施体系。在实际的安全开发工作中无论是做安全 SDK、写加解密模块还是做接口鉴权都会跟证书体系打交道。面试官问这个不单是考概念更是在考察你是否理解整个信任模型的运作机制。4. 网络协议与系统安全基础这一部分的内容覆盖面比较广但难度不算高主要考察计算机网络的基础知识和主机安全的基本功。如果这部分失分太多说明基础还不够扎实建议回去重新过一遍《计算机网络》。4.1 TCP协议的细节考察对 TCP 的考察主要集中在三次握手、四次挥手和状态迁移。有一道题给出一台服务器的netstat -an输出让你根据SYN_RECV和TIME_WAIT的状态数量判断服务器是否正在遭受攻击。SYN_RECV状态堆积过多大概率是在被 SYN Flood 攻击。攻击者发送大量伪造源 IP 的 SYN 包服务器内核收到后回复 SYN-ACK 并等待 ACK但这个 ACK 永远不会来半连接队列很快被占满正常用户的连接请求就无法被处理。防御措施包括启用 SYN Cookie、调整半连接队列大小、配置专业的防 DDoS 设备。TIME_WAIT多反而是正常现象。主动关闭连接的一方在收到对方的 FIN 后会进入 TIME_WAIT 状态并等待 2MSL最大报文段生存时间后才会释放端口。这是为了保证最后一个 ACK 能被对方收到以及让旧连接中的残留报文在网络中消失。高并发短连接的服务端通常会有大量 TIME_WAIT可以通过开启tcp_tw_reuse和so_reuseport优化但这属于调优手段需要结合业务场景谨慎使用。4.2 HTTPS握手过程中的密钥协商试卷中有一道综合分析题从 TCP 三次握手写到 TLS 握手完成要求画出完整的消息交换流程。这个题在纸上画起来很费时间但它考察的知识点非常有价值。简述关键流程客户端发送 ClientHello携带支持的加密套件列表和随机数服务端回复 ServerHello选定加密套件发送证书和另一随机数客户端验证证书后生成预主密钥用服务端公钥加密传输双方通过相同的算法从三个随机数推导出会话密钥最后互发 Finished 消息确认握手完成。现代 TLS 1.3 简化了握手过程把大多数协商信息放在第一个往返中完成但原理依然是这个。理解这个流程对做安全开发很重要因为很多上层问题比如 session 复用、证书动态更新、抓包排查都建立在对握手过程的理解之上。4.3 主机安全基础计算机三级安全方向的考点在试卷中也有体现包括 Windows 和 Linux 的常见加固手段。Linux 侧的常用操作有关闭不必要服务、修改 SSH 默认端口和禁止 root 直接登录、配置防火墙策略iptables/firewalld、定期更新补丁、开启 auditd 审计日志。另外还有一道关于权限的命令题给一个文件权限-rwxr-xr--要求说明属主、属组和其他用户分别拥有哪些权限。这道题纯送分但依然有同学答错主要是混淆了读、写、执行的数字表示。我的建议是把这张对应表刻在脑子里r4w2x1755 表示属主可读写执行、属组可读执行、其他用户可读执行。5. 编码题与综合场景题深度解析这部分是把前面所有知识点串起来的压轴题也是最像真实工作场景的部分。我来详细说说当时的解题思路这道题几乎可以作为安全开发笔试的经典范例。5.1 如果让你从零实现一个安全的登录接口试卷的编程题是用任意语言实现一个登录接口要求考虑常见安全风险。这题拿到手不要急着写代码先罗列一下要防什么SQL 注入、暴力破解、会话固定、密码泄露、日志敏感信息泄露、传输层明文。我当时的实现思路是这样的# Python Flask 伪代码示例仅演示关键逻辑 import re import bcrypt from flask import request, session USERNAME_RE re.compile(r^[a-zA-Z0-9_]{4,20}$) def login(): username request.form.get(username, ) password request.form.get(password, ) # 1. 输入合法性校验 if not USERNAME_RE.match(username): return error(用户名格式不合法) if len(password) 128: return error(密码长度不合法) # 2. 查询用户使用预处理语句防SQL注入 user get_user_by_name(username) if not user: return error(用户不存在) # 3. 使用bcrypt校验密码避免时序攻击 if not bcrypt.checkpw(password.encode(utf-8), user.password_hash.encode(utf-8)): return error(密码错误) # 4. 登录成功后旋转会话ID防会话固定 session.clear() session[uid] user.id session[login_at] int(time.time()) return success(登录成功)防 SQL 注入用参数化查询防暴力破解我在接口层面加了 IP 用户名维度的失败次数计数连续失败超过 5 次锁定 15 分钟。这里有一个容易漏掉的细节用户不存在和密码错误的提示要统一否则攻击者可以通过报错信息爆破用户名。防密码泄露我明确选择了 bcrypt 哈希存储并且不在日志中记录密码相关的任何信息。防传输层明文我要求在 Nginx 层强制 HTTPS并在代码中检查request.is_secure。5.2 日志分析题的排查链路最后一类题目是日志分析给出一段 Nginx 访问日志其中有大量 404 请求路径包含../..、/etc/passwd、select、union等特征让你判断攻击类型并给出响应方案。这个题考察的是应急响应的第一反应。我的分析链路是先看攻击源 IP 是否集中在少数几个地址如果是说明是定向攻击再统计请求路径的特征../..指向路径穿越/etc/passwd说明在读取系统文件select和union说明在探测 SQL 注入点。综合来看这是一次自动化扫描与手工利用并存的攻击行为。响应方案分两层。第一层是临时止损在 WAF 或 Nginx 层封禁攻击源 IP并对包含敏感关键字如/etc/passwd、union select的请求直接返回 403。第二层是根因修复排查对应路径的代码是否存在文件读取和 SQL 拼接漏洞检查 Web 服务是否以低权限用户运行确认系统补丁是否最新同时检查同一段时间内是否存在其他异常登录行为。这个题的得分点不在答案本身而在你的思考过程是否完整。很多同学只回答了“这是扫描”没有给出处置建议更多人只说了“封 IP”没有提根因排查。做安全的都知道攻击者换个 IP 就能绕过封禁只有把漏洞本身修好了才算真正的事件处置结束。5.3 值得反思的几个细节复盘这份试卷有几个细节特别想提醒后来人。一是对时间的分配。我看到不少同学在密码学大题上花了太多时间写算法推导结果后面的编码题没时间做。实际上密码学部分占分不高按点得分即可编码题一写就是几十分性价比完全不同。我的建议是上场先把整张卷子扫一遍按“分值/时间”的性价比排序来安排答题顺序先拿最容易拿的分。二是实验环境的必要性。这份试卷的题目如果只看不练很难真正消化。比如 SQL 注入的各类绕过方式你至少要在本地搭一个 Sqli-labs 环境亲手打一遍把报错注入、盲注、堆叠注入都试过理解了原理笔试才能灵活应变。同样XSS 需要在 DVWA 里练习不同上下文环境的注入方式。三是软考和校招笔试的关系。很多同学问“考信息安全工程师软考对找安全开发工作有没有用”我的看法是软考覆盖的知识面广、成体系作为系统学习框架是有帮助的特别是“信息安全工程师教程第三版”里的内容和校招笔试的考点重合度确实不低。但软考偏重理论和管理校招笔试更偏实战和代码两者不能互相替代。如果时间有限可以先刷真题感受风格再针对弱项集中补。6. 备考思路与笔试技巧总结最后说一下我对这份试卷的总体判断和备考建议。事实上这类安全开发岗的笔试题每年都在变化但考察的核心能力始终是那几项扎实的 Web 安全基础、动手写代码的能力、排查问题的逻辑思维、对常见漏洞原理的深入理解。从备考策略上看我建议按四个阶段来准备每个阶段侧重点不同适合在校招季之前用两到三个月来系统推进。第一阶段打基础2周快速过一遍《白帽子讲Web安全》和 OWASP Top 10确保对各类漏洞类型、原理、防御手段有整体认知。这个阶段不用做太深目标是建立知识框架。第二阶段刷靶场4周把 Sqli-labs、XSS-labs、Upload-labs、DVWA 这类的靶场逐个刷完。这个阶段是实操能力提升最快的时期每一关都要搞清楚为什么这样绕过、为什么这样防御而不是单纯为了通关。第三阶段看源码审计案例2周去 GitHub 搜一些简单的 CMS 或开源项目尝试用代码审计的视角去读代码寻找 SQL 注入、文件上传、越权这类能看懂的漏洞。这个阶段能帮你建立“代码即攻击面”的意识对应试卷中的代码审计题非常有帮助。第四阶段模拟笔试1周找几套其他公司往年的安全岗笔试真题按真实考试时间限时完成重点训练时间分配和答题节奏。在校招笔试中还有一个容易被忽视的点卷面表达。安全开发岗位的笔试往往有主观题阅卷人最怕看到大片无法定位的模糊答案。比如问修复方案时要按照“首选方案辅助方案兜底措施”的结构去组织每一步写清楚操作路径和预期效果让阅卷人一眼看出你真的动手做过、思考过而不是背模板背出来的。踩过几次坑之后我个人最大的体会是不要把校招笔试当成考试去准备要把它当成一次能力体检。这几张试卷能检测出你离一个合格的安全开发工程师还差多远——SQL 注入漏洞看的是你有没有代码层防御的意识密码学题看的是你对安全基石的敬畏程度日志分析题看的是你面对真实攻击时的冷静程度。带着这种心态去刷题、去复盘收获会远超备考本身。 校招安全岗笔试复盘：Web安全、密码学与安全开发考点全解析
校招安全岗笔试没那么玄乎大部分题目其实是把大学四年零散的知识点串起来考。我把自己当年整理的一份“美丽联合2018校招信息安全开发工程师笔试试卷”的复盘笔记翻了出来结合后来做面试官、带新人的经验重新梳理了一遍今天一次性把里面的考点、解题思路和背后的坑都讲清楚。无论你是正在准备校招的应届生还是半路转行想做安全开发的朋友这份拆解应该都能帮你少走不少弯路。这份试卷覆盖的面很典型Web安全基础、密码学应用、漏洞原理与利用、网络协议分析、基础开发能力。难度大概在“科班学过、但没实战过也能及格”的水平但想拿高分光会背书不行得有真正的代码功底和排查思路。下面我们一块一块说。1. 试卷整体结构与命题逻辑拿到卷子先别急着做题我习惯先看一遍题目分布判断出题人的侧重点。这份试卷大致分为五个板块Web安全与漏洞分析、密码学基础、网络协议、编程与算法、综合场景题。每个板块的分值比重并不均匀Web安全明显是重头戏这符合“信息安全开发工程师”这个岗位的定位——既要懂攻更要懂防还要能写代码实现防御方案。从命题逻辑上看出题人有三个明显意图。第一个是考察基础是否扎实比如 SQL 注入的绕过方式、XSS 的几种类型区分这些是安全开发的底线知识。第二个是考察实战思维比如给一段代码让你找出漏洞并修复这比单纯问“什么是 CSRF”要难得多因为它要求你同时具备代码审计能力和修复方案的落地能力。第三个是考察知识面的广度密码学、网络协议、操作系统都有涉及毕竟安全开发工程师在日常工作中要跟各种系统打交道知识面太窄很容易漏掉风险点。另外我注意到这套试卷很注重“原理实践”的结合。比如密码学部分不是只让背算法名字而是给定场景让你选合适的加密方案还要说明为什么。这类题目其实就是实际工作的缩影——你不可能所有算法都精通但你必须知道在什么场景下选什么工具。1.1 岗位能力模型与考察重点“信息安全开发工程师”这个岗位名称已经说明了要求本质是开发岗位但开发的对象是安全能力。所以试卷里编程题和漏洞分析题是交织在一起的比如让你实现一个简单的登录接口同时要考虑 SQL 注入、暴力破解、会话固定等安全问题或者给你一段有漏洞的代码让你在修复的同时保证业务功能不变。这种出题方式对纯安全研究型选手不太友好因为只懂攻击不懂修复拿不到分对纯业务开发选手同样不友好因为代码写得再漂亮安全漏洞一抓一把也是白搭。我的感受是这份试卷想筛选的是那种“能写一手干净代码同时脑子里时刻有攻防意识”的工程师。还有一个容易被忽略的点试卷里有些题目看起来是考知识点实际上是在考察你的排查思路。比如给你一份日志让你定位一次攻击行为这类题没有标准答案但你的分析路径是否合理、能否从蛛丝马迹中还原攻击链面试官一眼就能看出来。这种能力不是靠刷题能练出来的需要平时多读真实攻击案例、多做日志分析。2. Web安全核心考点拆解Web安全部分占了整张试卷将近三分之一的分值题目类型也比较多样从选择题到代码审计都有。我把其中比较有代表性的几类题目单独拿出来拆一下这些考点放到今天依然没有过时照样是面试高频题。2.1 SQL注入的一线实战细节试卷里有一道典型的 SQL 注入题目给了一段拼接 SQL 的登录代码问如何绕过登录、如何修复。代码大概是这样的$sql SELECT * FROM users WHERE name{$username} AND pass{$password};第一问很简单用万能密码 OR 11就能绕过这是几乎所有安全科普文章都会提到的点。但第二问“如何修复”才是拉开差距的地方。我看到很多同学的答案只写了“用预处理”这当然没错但缺乏细节。我建议的答案结构是这样首选方案使用 PDO 预处理 参数绑定。核心逻辑是 SQL 语句结构预先编译用户输入只作为参数值传递数据库不会把输入内容当作 SQL 指令执行。代码实例如下$stmt $pdo-prepare(SELECT * FROM users WHERE name ? AND pass ?); $stmt-execute([$username, $password]);辅助方案对输入做白名单校验。比如用户名只允许字母、数字和下划线用正则表达式过滤掉其他字符。但要注意白名单校验是纵深防御的一环不能替代预处理作为唯一防线。其他加固措施最小化数据库账号权限Web应用不使用 DBA 权限连接数据库关闭错误信息回显防止攻击者通过报错信息获取表结构。另外一个值得注意的坑是很多人以为过滤了单引号就万事大吉但实际上宽字节注入、二次注入、order by 注入等变种都能绕过简单的过滤。宽字节注入在 GBK 编码下尤为常见攻击者通过%bf%27这类编码让转义函数失效。所以我一向强调过滤函数只能作为辅助预处理的地位不可动摇。2.2 XSS的类型区分与利用链路XSS 的题目在试卷中主要是给三段代码分别对应反射型、存储型、DOM 型让你写出区别和对应的防御方案。这道题表面上是概念题实际上考察的是你对浏览器安全模型的深入理解。反射型 XSS 最容易理解恶意脚本在请求 URL 中服务端直接拼接进 HTML 返回。它的特点是一次性的攻击者需要诱导受害者点击构造好的链接。存储型 XSS 更危险恶意脚本被持久化存储在服务器数据库中所有访问该页面的用户都会中招典型的场景是评论区、用户昵称等。DOM 型 XSS 则不太一样它不经过服务端纯粹是前端 JavaScript 把不可信内容插入到了 DOM 中比如document.getElementById(user).innerHTML location.hash.substring(1);这种漏洞在纯前端项目里非常常见也是很多同学容易忽略的盲区。防御方案要分场景说。对于反射型和存储型核心是输出编码在 HTML 上下文中转义、、、、在 JavaScript 上下文中需要做 Unicode 转义在 URL 属性中要做 URL 编码。不同场景的编码规则不同混用就会出问题。对于 DOM 型 XSS核心是避免使用innerHTML、document.write这类危险函数优先使用textContent或者安全的 DOM 操作 API。我还想多说一句XSS 的利用链路经常被校招生忽视。一道进阶题问“存储型 XSS 除了弹窗还能干什么”大多数人的答案是盗 Cookie但更完整的回答应该包括结合 CSRF 漏洞修改用户资料、构造钓鱼页面、内网探测、结合浏览器漏洞实现 RCE。理解了利用链路你才真正理解为什么 XSS 被 OWASP 列为最普遍的漏洞之一。2.3 CSRF与SSRF的逻辑对比试卷里有一道对比题要求说明 CSRF 和 SSRF 的相同点与不同点。这两个漏洞名字很像但攻击链路完全不同很多同学容易混淆。CSRF跨站请求伪造的核心是利用了浏览器的 Cookie 自动携带机制。用户在登录状态下访问攻击者构造的恶意页面该页面偷偷向目标网站发送请求因为浏览器会自动带上用户的 Cookie服务端无法区分这个请求是否为用户本人发起的。经典的修复方案是加 Token 校验、二次确认弹窗、SameSite Cookie 属性、校验 Referer。SSRF服务端请求伪造则是利用服务端的请求功能让服务器去访问攻击者指定的内网地址。比如某个功能需要从远程服务器拉取图片攻击者把 URL 改成http://127.0.0.1:6379/就可能探测到内网中的 Redis 服务。SSRF 的防御要从协议白名单、IP 地址黑名单禁用回环地址和私网地址、Nginx 层控制内网访问入口、限制服务端请求的重定向行为等几个维度同时发力。这两个漏洞虽然不同但有一个共同点都是因为对请求的来源或目标缺乏严格校验。这也是安全开发中一个非常核心的思想——不要默认信任任何输入包括请求中的来源信息和自定义的 URL 参数。3. 密码学考点与应用场景分析密码学在试卷中占比不大但每一分都是送分题丢了很可惜。这部分考察的重点不是让你徒手实现 RSA而是考察你对常见加密算法的特征、适用场景和安全等级的掌握程度。3.1 对称加密与非对称加密的选择试卷中的一道典型题目给出四种应用场景分别是大数据量文件加密、密钥分发、数字签名、Web通信握手要求选择合适的加密算法并说明原因。正确答案的核心逻辑是对称加密效率高适合加密大量数据密钥分发是难题非对称加密安全但计算开销大适合加密少量关键数据如对称密钥、数字签名、密钥协商。所以实际系统中几乎清一色用混合加密方案先用非对称加密安全地协商出对称密钥再用对称密钥加密实际数据。HTTPS 的 TLS 握手就是这么干的用 ECDHE 或 RSA 做密钥协商用 AES 加密应用数据。还有一类题目是给出一段加密过程的伪代码让你判断哪里有问题。常见陷阱包括使用 ECB 模式的 AES这种模式明文相同的分组会得到相同的密文会暴露明文统计规律应该用 CBC 或 GCM使用不随机的 IVIV 必须随机且每次不同签名时先加密后签名导致的安全问题。这些细节在课本上都是一句话带过但在实际工程里却是漏洞的高发区。3.2 哈希算法的正确使用方式哈希算法部分有一道很经典的题目给定用户密码存储方案让你指出问题并优化。原方案是直接对MD5(password)存库。这题的错误点太明显了MD5 速度太快GPU 每秒可以算几十亿次配合彩虹表弱密码基本秒破。正确的存储方案应该使用专门的密码哈希算法比如 bcrypt、scrypt、Argon2。这些算法的一个共同特征是计算速度可以调节故意设计得“慢”让每一次破解尝试都付出高昂的算力代价。以 bcrypt 为例它的 cost factor 每增加 1计算时间翻倍我现在一般建议 cost 至少设为 10 或 12。另一个容易忽略的考点是“哈希不是加密”两者有本质区别。哈希是不可逆的单向函数加密是可逆的变换做题时如果把这两个概念混用会被扣掉不少分。还有盐salt的问题盐要随机、每用户不同、长度足够至少16字节才能有效抵御彩虹表和预计算攻击。3.3 数字签名与证书体系试卷在这一块考得比较浅主要是问数字签名的作用和 HTTPS 证书的信任链。数字签名的作用有三点完整性、认证性、不可否认性。签名方用私钥签名验证方用公钥验证由于私钥只有签名方持有所以可以证明消息的来源。涉及到 HTTPS 证书信任链的题目更有意思它会让你描述从浏览器到服务器证书的验证过程。完整的过程是服务器返回证书链浏览器从站点证书开始逐级向上验证签名的有效性一直到内置的根证书。如果中间某一级证书过期、被吊销或者签发机构不受信任浏览器就会给出安全警告。这道题背后的目的是让你理解 PKI公钥基础设施体系。在实际的安全开发工作中无论是做安全 SDK、写加解密模块还是做接口鉴权都会跟证书体系打交道。面试官问这个不单是考概念更是在考察你是否理解整个信任模型的运作机制。4. 网络协议与系统安全基础这一部分的内容覆盖面比较广但难度不算高主要考察计算机网络的基础知识和主机安全的基本功。如果这部分失分太多说明基础还不够扎实建议回去重新过一遍《计算机网络》。4.1 TCP协议的细节考察对 TCP 的考察主要集中在三次握手、四次挥手和状态迁移。有一道题给出一台服务器的netstat -an输出让你根据SYN_RECV和TIME_WAIT的状态数量判断服务器是否正在遭受攻击。SYN_RECV状态堆积过多大概率是在被 SYN Flood 攻击。攻击者发送大量伪造源 IP 的 SYN 包服务器内核收到后回复 SYN-ACK 并等待 ACK但这个 ACK 永远不会来半连接队列很快被占满正常用户的连接请求就无法被处理。防御措施包括启用 SYN Cookie、调整半连接队列大小、配置专业的防 DDoS 设备。TIME_WAIT多反而是正常现象。主动关闭连接的一方在收到对方的 FIN 后会进入 TIME_WAIT 状态并等待 2MSL最大报文段生存时间后才会释放端口。这是为了保证最后一个 ACK 能被对方收到以及让旧连接中的残留报文在网络中消失。高并发短连接的服务端通常会有大量 TIME_WAIT可以通过开启tcp_tw_reuse和so_reuseport优化但这属于调优手段需要结合业务场景谨慎使用。4.2 HTTPS握手过程中的密钥协商试卷中有一道综合分析题从 TCP 三次握手写到 TLS 握手完成要求画出完整的消息交换流程。这个题在纸上画起来很费时间但它考察的知识点非常有价值。简述关键流程客户端发送 ClientHello携带支持的加密套件列表和随机数服务端回复 ServerHello选定加密套件发送证书和另一随机数客户端验证证书后生成预主密钥用服务端公钥加密传输双方通过相同的算法从三个随机数推导出会话密钥最后互发 Finished 消息确认握手完成。现代 TLS 1.3 简化了握手过程把大多数协商信息放在第一个往返中完成但原理依然是这个。理解这个流程对做安全开发很重要因为很多上层问题比如 session 复用、证书动态更新、抓包排查都建立在对握手过程的理解之上。4.3 主机安全基础计算机三级安全方向的考点在试卷中也有体现包括 Windows 和 Linux 的常见加固手段。Linux 侧的常用操作有关闭不必要服务、修改 SSH 默认端口和禁止 root 直接登录、配置防火墙策略iptables/firewalld、定期更新补丁、开启 auditd 审计日志。另外还有一道关于权限的命令题给一个文件权限-rwxr-xr--要求说明属主、属组和其他用户分别拥有哪些权限。这道题纯送分但依然有同学答错主要是混淆了读、写、执行的数字表示。我的建议是把这张对应表刻在脑子里r4w2x1755 表示属主可读写执行、属组可读执行、其他用户可读执行。5. 编码题与综合场景题深度解析这部分是把前面所有知识点串起来的压轴题也是最像真实工作场景的部分。我来详细说说当时的解题思路这道题几乎可以作为安全开发笔试的经典范例。5.1 如果让你从零实现一个安全的登录接口试卷的编程题是用任意语言实现一个登录接口要求考虑常见安全风险。这题拿到手不要急着写代码先罗列一下要防什么SQL 注入、暴力破解、会话固定、密码泄露、日志敏感信息泄露、传输层明文。我当时的实现思路是这样的# Python Flask 伪代码示例仅演示关键逻辑 import re import bcrypt from flask import request, session USERNAME_RE re.compile(r^[a-zA-Z0-9_]{4,20}$) def login(): username request.form.get(username, ) password request.form.get(password, ) # 1. 输入合法性校验 if not USERNAME_RE.match(username): return error(用户名格式不合法) if len(password) 128: return error(密码长度不合法) # 2. 查询用户使用预处理语句防SQL注入 user get_user_by_name(username) if not user: return error(用户不存在) # 3. 使用bcrypt校验密码避免时序攻击 if not bcrypt.checkpw(password.encode(utf-8), user.password_hash.encode(utf-8)): return error(密码错误) # 4. 登录成功后旋转会话ID防会话固定 session.clear() session[uid] user.id session[login_at] int(time.time()) return success(登录成功)防 SQL 注入用参数化查询防暴力破解我在接口层面加了 IP 用户名维度的失败次数计数连续失败超过 5 次锁定 15 分钟。这里有一个容易漏掉的细节用户不存在和密码错误的提示要统一否则攻击者可以通过报错信息爆破用户名。防密码泄露我明确选择了 bcrypt 哈希存储并且不在日志中记录密码相关的任何信息。防传输层明文我要求在 Nginx 层强制 HTTPS并在代码中检查request.is_secure。5.2 日志分析题的排查链路最后一类题目是日志分析给出一段 Nginx 访问日志其中有大量 404 请求路径包含../..、/etc/passwd、select、union等特征让你判断攻击类型并给出响应方案。这个题考察的是应急响应的第一反应。我的分析链路是先看攻击源 IP 是否集中在少数几个地址如果是说明是定向攻击再统计请求路径的特征../..指向路径穿越/etc/passwd说明在读取系统文件select和union说明在探测 SQL 注入点。综合来看这是一次自动化扫描与手工利用并存的攻击行为。响应方案分两层。第一层是临时止损在 WAF 或 Nginx 层封禁攻击源 IP并对包含敏感关键字如/etc/passwd、union select的请求直接返回 403。第二层是根因修复排查对应路径的代码是否存在文件读取和 SQL 拼接漏洞检查 Web 服务是否以低权限用户运行确认系统补丁是否最新同时检查同一段时间内是否存在其他异常登录行为。这个题的得分点不在答案本身而在你的思考过程是否完整。很多同学只回答了“这是扫描”没有给出处置建议更多人只说了“封 IP”没有提根因排查。做安全的都知道攻击者换个 IP 就能绕过封禁只有把漏洞本身修好了才算真正的事件处置结束。5.3 值得反思的几个细节复盘这份试卷有几个细节特别想提醒后来人。一是对时间的分配。我看到不少同学在密码学大题上花了太多时间写算法推导结果后面的编码题没时间做。实际上密码学部分占分不高按点得分即可编码题一写就是几十分性价比完全不同。我的建议是上场先把整张卷子扫一遍按“分值/时间”的性价比排序来安排答题顺序先拿最容易拿的分。二是实验环境的必要性。这份试卷的题目如果只看不练很难真正消化。比如 SQL 注入的各类绕过方式你至少要在本地搭一个 Sqli-labs 环境亲手打一遍把报错注入、盲注、堆叠注入都试过理解了原理笔试才能灵活应变。同样XSS 需要在 DVWA 里练习不同上下文环境的注入方式。三是软考和校招笔试的关系。很多同学问“考信息安全工程师软考对找安全开发工作有没有用”我的看法是软考覆盖的知识面广、成体系作为系统学习框架是有帮助的特别是“信息安全工程师教程第三版”里的内容和校招笔试的考点重合度确实不低。但软考偏重理论和管理校招笔试更偏实战和代码两者不能互相替代。如果时间有限可以先刷真题感受风格再针对弱项集中补。6. 备考思路与笔试技巧总结最后说一下我对这份试卷的总体判断和备考建议。事实上这类安全开发岗的笔试题每年都在变化但考察的核心能力始终是那几项扎实的 Web 安全基础、动手写代码的能力、排查问题的逻辑思维、对常见漏洞原理的深入理解。从备考策略上看我建议按四个阶段来准备每个阶段侧重点不同适合在校招季之前用两到三个月来系统推进。第一阶段打基础2周快速过一遍《白帽子讲Web安全》和 OWASP Top 10确保对各类漏洞类型、原理、防御手段有整体认知。这个阶段不用做太深目标是建立知识框架。第二阶段刷靶场4周把 Sqli-labs、XSS-labs、Upload-labs、DVWA 这类的靶场逐个刷完。这个阶段是实操能力提升最快的时期每一关都要搞清楚为什么这样绕过、为什么这样防御而不是单纯为了通关。第三阶段看源码审计案例2周去 GitHub 搜一些简单的 CMS 或开源项目尝试用代码审计的视角去读代码寻找 SQL 注入、文件上传、越权这类能看懂的漏洞。这个阶段能帮你建立“代码即攻击面”的意识对应试卷中的代码审计题非常有帮助。第四阶段模拟笔试1周找几套其他公司往年的安全岗笔试真题按真实考试时间限时完成重点训练时间分配和答题节奏。在校招笔试中还有一个容易被忽视的点卷面表达。安全开发岗位的笔试往往有主观题阅卷人最怕看到大片无法定位的模糊答案。比如问修复方案时要按照“首选方案辅助方案兜底措施”的结构去组织每一步写清楚操作路径和预期效果让阅卷人一眼看出你真的动手做过、思考过而不是背模板背出来的。踩过几次坑之后我个人最大的体会是不要把校招笔试当成考试去准备要把它当成一次能力体检。这几张试卷能检测出你离一个合格的安全开发工程师还差多远——SQL 注入漏洞看的是你有没有代码层防御的意识密码学题看的是你对安全基石的敬畏程度日志分析题看的是你面对真实攻击时的冷静程度。带着这种心态去刷题、去复盘收获会远超备考本身。