企业官网建设流程全解析

每年九、十月份，安全方向的应届生都会迎来一波笔试轰炸，而奇安信作为国内安全圈的头部厂商，它的秋招研发安全方向试卷，基本可以当作一次安全研发岗位的“能力体检”。我手头刚好存了一份2020年的真题回忆版，最近不少学弟学妹问我这套卷子到底考什么、该怎么准备，干脆把整套试卷的知识点、考点逻辑和备考思路完整拆一遍。

先说结论：这套卷子整体难度偏中上，不是那种背背书就能过的考试。它考察的核心不是“你知道多少漏洞名字”，而是“你能不能理解漏洞产生的根因，并给出可落地的修复方案”。也就是说，它考的是安全研发思维，而非单纯的安全测试思维。对于目标是安全研发、安全SDLC、代码审计、安全工具开发这类岗位的同学来说，这套题是一个非常好的自测标杆。

1. 试卷整体设计与考察目标拆解

1.1 从岗位JD反推试卷的出题逻辑

奇安信的安全研发岗，日常工作不是拿扫描器扫漏洞，而是要把安全能力“产品化”。比如web扫描器的规则引擎、RASP的Hook逻辑、SDL安全网关的策略编排、代码卫士的缺陷分析模型，这些都需要研发同学既懂漏洞原理、又懂工程实现。所以试卷的出题逻辑很清晰：

• 第一层：通用基础——数据结构、操作系统、网络协议，这些是研发岗的底子，不过占比不高。
• 第二层：安全基础——Web漏洞原理、密码学基础、认证授权机制，考察你是否具备安全领域的常识。
• 第三层：研发视角的安全能力——给你一个漏洞场景，你能写检测规则吗？给你一段代码，你能找出问题并给出修复方案吗？这是整张卷子的重点，也是拉分的地方。

从我拿到的考题记忆来看，Web安全部分占了约40%的权重，二进制与系统安全约20%，密码学约15%，剩下的是数据结构、编程语言和综合设计题。这个比例和奇安信的产品线是对得上的——Web（网站防护、云WAF）、终端（终端安全、EDR）、数据（数据审计、隐私计算）是三大业务支柱，所以考纲也围绕这些方向展开。

1.2 研发安全方向与安全研究方向的区别

很多同学容易把“研发安全”和“安全研究”搞混，但它们的考察侧重点有明显差别：

• 安全研究岗更看重漏洞挖掘能力，比如给你一个目标，你能不能挖到0day，所以笔试里PWN、逆向、Fuzzing的深度会更重。
• 研发安全岗更看重工程化能力，比如给你一个漏洞情报，你能不能写出检测POC脚本；给你一段业务代码，你能不能设计一个修复方案；给你一个安全需求，你能不能设计一套权限模型。这套卷子里就明确体现了这一点——题目不会让你直接去攻破某个二进制的栈溢出，而是给你一段存在问题的代码，问你如何从研发角度规避风险。

所以在准备这套卷子时，一个关键策略是：不要只背漏洞原理，一定要练“如何用代码解决安全问题”。

2. 核心知识点拆解：Web安全篇

2.1 SQL注入：从原理到参数化查询的落地

这一块几乎是必考的，而且奇安信的题不会只问“什么是SQL注入”，它会给你一段拼接SQL的代码，让你指出问题并给出两种修复方案。常见考点：

• 注入点判断：字符型还是数字型，闭合方式是什么。
• 绕过技巧：注释符绕过、大小写绕过、编码绕过、等价函数替换。
• 修复方案：参数化查询、白名单校验、最小权限数据库账号。

说实话，参数化查询是标准答案，但很多人忽略了“存储过程也可能存在注入”这个坑。如果存储过程内部使用了动态SQL拼接，参数化外部调用并不能完全挡住注入。这道题的满分回答应该加上一句：“需同步审查存储过程内部是否存在动态拼接，并对存储过程的入参做类型和长度校验。”这会让你的答案瞬间有区分度。

还有一个容易被忽略的考点是order by后的注入。参数化查询无法处理排序字段，这时候只能靠白名单映射。奇安信的题里考过类似的变种，它考察的不是你会不会写SQL，而是你有没有真实处理过这类边界场景。

2.2 XSS的三种类型与防护差异

XSS也是必考题，而且奇安信比较喜欢考“输出编码”这个点。你要分清楚：

• 反射型XSS：数据在URL参数中，未经过滤直接输出到页面。
• 存储型XSS：数据入库后再输出到页面，危害更大。
• DOM型XSS：纯前端问题，数据经过DOM操作被当作HTML执行。

防护方案也一样要分清：反射型和存储型主要靠服务端输出编码，DOM型主要靠前端编码。很多人答XSS修复直接写一句“对用户输入做过滤”，这种答案是不及格的。正确的思路是：输入侧做合法性校验（白名单），输出侧做上下文感知编码（HTML编码、JS编码、URL编码要分开），同时开启CSP限制脚本执行来源。

我印象比较深的是，这套题里有一道DOM XSS的题目，给了一段vue的v-html渲染用户评论的代码，让指出问题。这道题很典型地反映了安全研发的日常——框架的自动转义能挡住大部分存储型XSS，但v-html、dangerouslySetInnerHTML这类“逃生舱口”一旦被业务误用，就会直接击穿框架的安全机制。所以你在作答时，如果能提到“对需要使用v-html的业务场景，必须在服务端进行白名单过滤，不能只依赖前端转义”，会是一个不错的加分点。

2.3 CSRF与SSRF：两个容易混淆的请求类漏洞

CSRF（跨站请求伪造）和SSRF（服务端请求伪造）名字里都带“Request”，但一个是“借用户的身份发请求”，一个是“借服务器的身份发请求”，考点完全不同。

CSRF的修复方案有标准套路：同源检测（校验Referer/Origin）+ Token校验 + 敏感操作二次验证。不过这里有一个在实际开发中非常容易被忽略的细节：Token不要放在URL参数里，因为URL会进日志，Token一旦进了日志就相当于泄露了。很多公司的安全扫描器都能扫出URL中带Token的问题，奇安信作为做扫描器起家的厂商，对这种细节非常敏感。

SSRF考察的核心是“服务端发起HTTP请求时如何限制目标地址”。修复思路包括：

• 解析URL后对host做内网IP段（10.x、172.16-31.x、192.168.x、169.254.x等）的黑名单拦截。
• 注意DNS Rebinding——解析后校验通过，但真正请求时DNS解析结果已变。所以严谨的做法是在建立连接时再次校验IP，或者直接使用IP而不使用域名发起请求。

2.4 文件上传与路径遍历：奇安信热词里的重点

在热词里能看到“奇安信输入验证：路径遍历”这个搜索词，看来很多人对这类漏洞比较头疼。文件上传和路径遍历在安全研发方向是高频考点，因为它们的修复方案和开发工程结合得很紧密。

文件上传的常见考点：

• 校验文件扩展名（黑名单还是白名单？正确答案是白名单+大小写归一化）。
• 校验文件头（Magic Number），但要同步校验文件内容，防止图片马。
• 存储目录与Web根目录分离，上传目录禁止执行脚本（Nginx配置location ~ .php$ { deny all; }）。
• 文件名随机化，避免用户可控文件名导致覆盖或路径穿越。

路径遍历（Path Traversal）的题目则常常结合文件下载功能来考。核心修复方案：

• 对用户传入的文件名先做basename处理，只取文件名部分。
• 使用路径拼接后做真实路径的规范化（realpath），再校验拼接结果是否位于允许的目录前缀内。
• 在代码里不要直接信任用户输入的“相对路径”参数，能用ID映射文件就尽量用ID映射。

我在实际代码审计中见过一个很典型的案例：后端用new File(BASE_DIR, userInput).getCanonicalPath()，但用户传入的是../../etc/passwd，getCanonicalPath返回的路径在BASE_DIR之外，代码却没有做startWith校验。这个问题恰好就是试卷里那道路径遍历题的翻版。所以看到这里，建议你把这套思路记下来，笔试时直接用。

3. 核心知识点拆解：二进制与系统安全篇

3.1 缓冲区溢出与保护机制

奇安信虽然是综合性安全厂商，但它的终端安全产品线（天擎、EDR）在业界是主流产品，所以对二进制基础也有要求。这一部分考点集中在：

• 栈溢出原理：函数调用栈结构、返回地址覆盖、EBP链劫持。
• 堆溢出原理：chunk结构、unlink攻击、fastbin attack（深度可浅可深）。
• 保护机制：NX、ASLR、PIE、Canary、RELRO——你要能解释每种机制防的是什么攻击类型。
• 利用缓解：Stack Canary的线程局部存储（TLS）存放位置，以及如何通过泄露Canary值来绕过。

这部分题目通常不会让你完整地写出一个利用链，更多是考察对保护机制的理解，比如“开启了ASLR和NX，还能不能执行栈上的shellcode？”答案是“不能，可以先做ROP，再配合信息泄露绕过ASLR”。能把这个逻辑链条讲清楚，就说明你真正理解了，而不是死记硬背。

3.2 整数溢出与逻辑漏洞

虽然整数溢出看着是二进制方向的知识，但在安全研发岗位的实际工作中，它往往会变成业务逻辑漏洞。比如：

• 金额计算时用int存储，用户通过负数或超大数绕过余额校验。
• 数量字段在乘法运算时溢出，导致实际扣减金额异常。
• 数组长度用int接收，但分配内存时以size_t处理，负数转为超大正数，导致拒绝服务或堆溢出。

试卷里有一道题就是给了一段数组扩容的C语言代码，让你指出其中的整数溢出问题并修复。标准修复方案是：扩容前检查新大小是否大于旧大小，且小于约定的最大值（如if (new_size < old_size || new_size > MAX_SIZE) return -1;）。这种题目非常能体现代码审计能力，建议在准备时把OWASP的C/C++安全编码规范过一遍，很有帮助。

3.3 提权与权限维持

奇安信终端安全产品日常对抗的就是提权和权限维持，所以笔试题也常出现这类场景题。比如：

• 内核提权漏洞的分类：条件竞争（TOCTOU）、未初始化变量、释放后使用（UAF）、符号链接攻击。
• 常见权限维持手段：注册表自启动、计划任务、WMI事件订阅、服务替换、进程注入。

在这套题里，这类问题通常会以“给你一段Windows注册表操作代码，问你有什么安全风险”的形式出现。它考察的不是你会不会利用，而是你能不能站在安全研发的角度去发现并封堵这个风险点。作答时思路要清晰：风险是什么、危害路径是什么、如何通过代码层修复（比如校验注册表写入权限、使用SEHOP/CFG等缓解机制、对关键路径加ACL）。

4. 核心知识点拆解：密码学与安全协议篇

4.1 对称加密与非对称加密的工程选型

密码学的考点比较稳定：对称加密（AES、DES、3DES）、非对称加密（RSA、ECC）、哈希函数（MD5、SHA-1、SHA-256）和消息认证码（HMAC）。但奇安信的考法会落到工程选型上，比如：

• 为什么AES比DES安全？AES的密钥长度128/192/256，DES只有56位有效密钥，暴力破解成本差距巨大。
• 为什么生产环境不能使用ECB模式？因为相同的明文块会产生相同的密文块，会泄露明文的结构信息。
• 正确用法是什么？CBC模式要使用随机IV，GCM模式自带认证，是目前推荐的首选。
• RSA使用时的注意事项：密钥长度至少2048位、使用OAEP填充而不是PKCS#1 v1.5（后者存在Bleichenbacher攻击）、私钥不传前端。

有一个容易踩坑的知识点：哈希不是加密。MD5和SHA-1被攻破指的是碰撞攻击和碰撞成本降低，但它们依然是“不可逆”的单向函数。对于密码存储，正确方案是使用bcrypt/scrypt/Argon2这类慢哈希算法，并且每个用户使用独立的盐。只做一次MD5就存库的做法在笔试里写出来，基本就是送命题。

4.2 HTTPS与TLS握手的常见问题

这一块考的并不是TLS协议完整握手流程的具体字段，而是从研发运维视角考察常见的安全配置问题：

• TLS版本过低：TLS 1.0/1.1存在BEAST和POODLE攻击，应禁用，最低启用TLS 1.2。
• 弱加密套件：RC4、3DES、CBC模式的套件应禁用，优先使用GCM模式的AEAD套件。
• 证书校验：客户端在请求HTTPS接口时，如果直接信任所有证书（verify=False），就会沦为中间人攻击的活靶子。
• 会话恢复（Session ID/Session Ticket）的安全问题：会话票据的密钥要定期轮换。

这里特别提一个容易被忽略的点：客户端证书校验与证书固定（Certificate Pinning）。移动端App如果只做宿主校验、不做证书固定，攻击者可以装个抓包代理证书就能解密全部流量，这在安全研发面试里是个高频追问点。试卷里虽然没有直接考，但如果你在作答HTTPS主题时主动提到，会显得对工程实践非常熟悉。

4.3 JWT与Session的安全设计

JWT几乎是现代Web开发必考内容，安全方向的试卷也不会放过。常见考点：

• JWT的三段结构：Header.Payload.Signature，签名算法不能设为none。
• 算法混淆攻击：攻击者把RS256改成HS256，用公钥当HMAC密钥来签名，如果服务端没正确校验算法类型就会被绕过。
• Token泄露风险：放在localStorage里容易被XSS窃取，放在Cookie里需设置HttpOnly和Secure标志。
• 过期时间：access token短期有效，refresh token长期有效，但要支持撤销机制。

和Session对比时，有一个很实际的视角：Session状态存在服务端，天然可以主动踢人，但分布式环境下要引入集中式存储（Redis），多了一层运维成本。JWT无状态，扩容方便，但撤销困难。安全研发岗位在日常做方案选型时，必须权衡这两个方案的“安全性-便利性”曲线，而不是无脑选JWT。

5. 实操过程与核心环节实现

5.1 用一道模拟题走通“发现-分析-修复”全流程

为了让你更直观地感受这套卷子的答题节奏，我用一道改编自该试卷风格的题目，完整演示一遍答题思路。

题目：某系统提供一个文件下载接口/download?filename=../../../../etc/passwd，后端核心代码如下：

public void download(String filename, HttpServletResponse response) { String basePath = "/data/web/files/"; File file = new File(basePath + filename); ... }

第一步：确认漏洞类型与危害。这是一个典型的路径遍历漏洞。攻击者利用../向上跳转目录，可读取服务器上任意有权限读取的文件，包括/etc/passwd、应用配置文件（可能含数据库密码）、SSH密钥等。

第二步：分析根因。代码直接把用户可控参数拼接到文件路径中，没有做路径归一化和前缀校验，导致..序列生效。

第三步：设计修复方案。标准修复方式如下：

public void download(String filename, HttpServletResponse response) { String basePath = "/data/web/files/"; // 1. 去掉路径中的目录部分，只取文件名 String safeName = new File(filename).getName(); // 2. 拼接并获取规范化路径 Path base = Paths.get(basePath).toAbsolutePath().normalize(); Path target = Paths.get(basePath, safeName).toAbsolutePath().normalize(); // 3. 校验目标路径是否仍在basePath之下 if (!target.startsWith(base)) { throw new SecurityException("非法路径"); } ... }

这样修复后，即使攻击者传入../../etc/passwd，getName()会直接取到passwd，拼到/data/web/files/passwd，由于该文件不存在，无法读取。而且即便有人尝试其他绕过手段，startsWith校验也会拦截路径越界。

这道题的完整作答中还应该补充一句：项目里建议对所有文件操作都使用Path.normalize()并做前缀校验，不能只过滤../字符串，因为在URL解码、双写编码、Unicode归一化等场景下，简单的字符串过滤很容易被绕过。

5.2 安全编码规范与SDL流程的结合

奇安信内部推行安全开发流程（SDL），笔试里也常以“研发提交代码时应该做哪些安全自测”来出题。这个问题的满分答案是：

• 静态代码扫描：在上线前用代码卫士这类工具扫描，重点检查SQL注入、XSS、文件操作、反序列化等风险点。
• 依赖安全检查：排查第三方组件是否存在已知CVE，比如Fastjson、Log4j2这类高危组件，要建立版本台账。
• 自测安全用例：对用户输入做边界测试，包括超长输入、特殊字符、空值、并发请求，确保代码不异常崩溃。
• 敏感信息检查：提交的代码里不出现硬编码密码、Token、AK/SK，日志里不打印身份证号、手机号等个人敏感信息。

这套答案的逻辑其实和整张试卷的考察方向是匹配的，也很好地呼应了热词里出现“奇安信代码卫士工具下载”的原因——代码卫士正是SDL中静态扫描这一环的落地产品。

5.3 安全工具链的选型与落地

试卷中还有一道综合性题目，问“如果你是一个安全研发，你会如何为团队选择安全工具链”。这类题看似开放，但其实有明确的评分要点：

• 开源与商业的对比：商业产品（如奇安信代码卫士、天擎）的优势是规则库更新快、误报率经过调优；开源产品（如Semgrep、CodeQL、Trivy）的优势是灵活、可控、成本低。
• 与CI/CD流水线的集成：工具如果不能嵌入Jenkins流水线或GitLab CI，那就只能靠人工触发，效果大打折扣。
• 漏洞管理闭环：扫描发现问题只是一个开始，还需要和缺陷管理系统（如Jira）打通，建立从发现、跟踪、修复、复测的闭环流程。

这类题考察的是你对“安全研发”这个岗位的理解是否完整。它不是问你会不会写代码、会不会挖漏洞，而是问你能不能从工程体系和流程制度上把安全落地，这是区分初级和高级候选人的关键。

6. 常见问题与排查技巧实录

6.1 常见失分点速查表

这段时间我帮不少人复盘过这套卷子，也看过一些分数不理想的答卷，总结出几个典型的失分点。

6.2 时间分配建议

整套试卷我估算的答题时间是120分钟，题量在30题左右（选择、填空、简答、编程各若干）。比较推荐的时间分配是：

• 选择题与填空题：控制在30分钟以内，不会的别死磕，先标记跳过。
• 简答题与代码审计题：这是大头，留60分钟，每题争取写满，不要只写一句话。
• 综合设计题/编程题：留30分钟，优先保证主体思路清晰、代码有正确逻辑框架，不要过度纠结编译级细节。

如果碰到完全没思路的题目，我的建议是写下“我知道的相关知识 + 我的分析思路”，多少能拿一些步骤分，直接空着是最亏的。

6.3 复盘总结时容易被忽略的三个方向

第一个方向是业务逻辑漏洞。常规漏洞靠工具能扫出来，但越权的检测往往需要代码审计中对接口权限设计有敏感度。这一块推荐研究一下OWASP“Horizontal and Vertical Access Control”这一章，配合实战案例来理解IDOR（不安全的直接对象引用）。

第二个方向是云原生安全。2020年之后，容器逃逸、K8s配置错误、镜像漏洞、供应链攻击在笔试题中出现的频率明显上升。如果目标是明年秋招，建议提前把Docker和Kubernetes的安全基线知识补齐。

第三个方向是个人知识库沉淀。安全研发的知识点非常零散，只看不写、不整理，过半个月就忘了。建议用Markdown维护一个安全研发知识库，按Web安全、二进制、密码学、系统安全、SDLC、云安全这样的维度分门别类，每学一个知识点就写一段“原理+场景+修复方案”的三段式笔记，刷题时直接查库，事半功倍。

7. 写在最后的一点经验

这套2020年的奇安信秋招卷，放到今天看，核心考点依然没有过时。安全研发这个方向，本质上要求的是“两手抓”：一只手能抓住漏洞原理的深层逻辑，另一只手能把修复方案落到真实的代码和系统架构里。单纯堆积漏洞利用技巧，或者单纯写增删改查的业务代码，都很难通过这类考试。

我的个人建议是，准备这类笔试时，把每一个考点都问自己三句话：第一句“这个漏洞为什么会产生”，第二句“用代码怎么修”，第三句“修完之后会不会引入新的问题”。把这三句话练成本能，笔试结果不管怎么样，对自己的提升都是实打实的。最后再分享一个备考小技巧：安全厂商出的技术博客和漏洞分析文章，往往就是笔试题的“题库风向标”，多刷、多看、多想，比盲目刷传统算法题有用得多。