企业官网建设流程全解析

2020年4月21日那天，我参加完奇安信Web安全工程师的笔试，出了考场先在楼下抽了根烟，脑子里的题目还在转。奇安信在政企和等保市场的覆盖量大家心里都有数，所以这场笔试既考“原理背得熟”，也考“你上手能不能打”，综合题和场景题明显偏向红队视角和防护落地。往回看，那套题其实是非常典型的“奇安信式考法”——不跟你玩虚的，重点全压在OWASP Top 10的实战化迁移、渗透测试报告的工程规范，以及代码层漏洞挖掘的思维深度上。

如果你正在准备这类岗位，或者想摸清国内头部安全厂商对一个Web安全工程师的技术预期，这篇文章值得你花十分钟读完。我会把那天涉及的题型、底层原理、还有我踩过的坑，结合当时项目里真实遇到的问题拆开讲，尽量把能直接“抄作业”的思路给到你。

1. 整体设计：4月21日这张卷子的出题逻辑

奇安信的题不是临时拼凑的，从“2020web安全工程师”这个岗位定位来看，出题人明显想把候选人分成两类：一类是只会用工具“打点”的脚本小子，另一类是能看懂漏洞根因、能写出有效修复建议的工程型选手。整张卷子给我的感觉就是“基础题确保下限，场景题拉高上限”。

1.1 为什么这场笔试很值得拉出来复盘

很多人觉得奇安信这类厂子笔试肯定很难，其实难不在原理本身，而在它的题目设计相当“反套路”。举个例子，它没有问你“SQL注入分哪几类”，而是直接抛出一个经过URL编码、且被WAF过滤了空格的注入点，问你“如果直接跑sqlmap会失败，你会怎么手工去注入”。

这种考法其实就是安全圈真实的工作状态。企业里最常遇到的不是“裸奔”的漏洞，而是被各种安全设备、代码层过滤、宿主机防御层层包裹的漏洞。4月21日这场笔试的“4月21日”这个时间点也很微妙——大概率是在年度安全项目集中开展的时候，团队需要即插即用的实战型Web安全人才。所以它强调“为什么”和“怎么绕过”，而不仅仅是“是什么”。

1.2 核心题型解构：从选择题到大题

按我的回忆，题型大概分三类，对应能力矩阵如下：

1. 基础理论题：占比约30%，覆盖HTTP协议细节、加解密基础、同源策略、DNS解析过程等。注意它不直接考“什么是XSS”，而是考“XSS与CSRF的交互链路”。
2. 漏洞利用与绕过题：占比约40%，给定一个模拟的请求包和部分后端代码片段，让你分析漏洞类型、构造出完整的利用请求，并说明如何规避WAF。
3. 综合实战与报告题：占比约30%，给定一个目标站的测试范围描述，让你写出完整的渗透测试步骤，并且输出结论性报告。这一步极其考验工程化能力。

我当时在最后的大题上花了一个小时，就是写一份“某金融业务系统渗透测试报告”的节选。那真不是套模板就能糊弄过去的，它要求你的风险评级、复现步骤、修复建议必须逻辑自洽，这是纯粹的经验活。

2. 把Web安全基础焊死：从原理到攻击链复述

在笔试里，基础题往往是滤网。很多朋友“会打”但“说不清”，在口头或书面表达时会露怯。奇安信的题特别注重“攻击链”的完整性——一个漏洞从出现到利用再到影响，中间每个链路节点都不能断。

2.1 必考组合之一：SQL注入与WAF绕过的底层逻辑

这部分涉及基础中的基础，但深度要超出常规。以当时试卷中一道典型的题为例，后端代码大致是：

String user = request.getParameter("user"); String query = "SELECT * FROM users WHERE name = '" + user + "'"; Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(query);

第一问很简单，闭合引号加注释，user=admin' or '1'='1' --+。考试的关键在第二问：如果这台机器前面有一层WAF，把select、union和空格都过滤了，你要怎么打？这里有一个常见的绕过公式：

• 用内联注释替换空格：/**/；
• 用大小写混合绕过关键字：UnIoN SeLeCt；
• 如果WAF很严格，还可以用编码辅助，比如二次URL编码。

我笔试时给出的请求体验证是这样写的：

GET /sqli.php?id=-1'/**/UnIoN/**/SeLeCt/**/1,user(),3--+ HTTP/1.1 Host: target.com

输出里再带一句：WAF本质上是基于正则的模式匹配，当payload拆分成多个不连续的片段，或者把关键字写成等价函数时（比如substr换成right(left())），正则就很容易漏掉。这就是“为什么我们要懂原理而不是只跑工具”的核心原因。

2.2 必考组合之二：XSS的三种形态与防护边界

除了SQL注入，XSS是另一个重头戏。笔试中的考察点是让候选人区分“存储型、反射型、DOM型”的触发位置和绕过机制。

我之前的项目里，遇到过一段很典型的修复不当代码：

var name = document.getElementById('username').value; document.getElementById('info').innerHTML = "欢迎回来," + name;

这段代码是纯DOM操作，如果name里包含<img src=x onerror=alert(1)>，那么他会直接执行。但如果后端用了htmlspecialchars把<>编码了，那么这段代码又不会触发。关键在于——存储型XSS的防护难点不在后端转义，而在输出上下文的精确判断。

考场上我给的建议分三层：

• 若插入在HTML标签内容中，用实体编码转义<>&"'；
• 若插入在标签属性中（如<a href="...">），必须针对属性做上下文感知编码，否则"绕过会直接引入新的事件；
• 若插入在<script>内部，仅做HTML实体编码是无效的，需要做JavaScript编码。

这不是考八股，是因为在实际渗透测试报告里，你给客户写“建议使用XSS Filter”，客户根本没法落地。奇安信这种厂商对工程师的要求就是“修复建议必须可执行到代码行级别”。

2.3 基础协议与逻辑漏洞：超乎想象的细节考察

考试还穿插了一些协议层面的题。比如典型的HTTP请求走私（Request Smuggling）场景，利用Content-Length和Transfer-Encoding解析差异导致前置代理和后端服务器对请求的边界判断不一致。在2020年那会儿这是红队特别喜欢打的一类点。

这里想说的是，做Web安全绝对不能只盯着“参数”本身，要时刻关注“数据链路”。从浏览器到WAF到反向代理到应用服务器，每一层对数据的解析都可能存在偏差，这种偏差就是漏洞。奇安信的题目里也包含了“如果请求包头存在重复的Host，代理和源站分别如何处理”这类细节，这些就要靠平时抓包时认真观察流量走向，而不是只会在Burp Suite里点Repeater。

3. 奇安信笔试的高频技术点：路径遍历与代码审计思维

“路径遍历”这个热词在网络上热度很高，恰恰是因为它太常见，却又容易被忽略。在4月21日那次笔试里，它作为一个独立的知识点出现了，结合了静态代码审计的逻辑。

3.1 路径遍历（目录穿越）：原理、绕过与实战复现

先看一段后端代码：

String fileName = request.getParameter("file"); File file = new File("/var/www/uploads/" + fileName); FileInputStream fis = new FileInputStream(file);

如果fileName直接传../../../etc/passwd，就能读到系统文件，这就是经典的路径遍历。但奇安信的题做了两个升级：

• 过滤了../：怎么办？用....//，后端如果只做了一次replace("../", "")，那么....//会变成../；
• 过滤了/：怎么办？可以采用URL编码%2f，如果后端接受了解码后的路径，就绕过了；在某些中间件上，还可以尝试..;/这种特殊路径分隔符。

我在笔试时给的利用案例是Windows环境下读取系统文件的构造：

GET /download.jsp?file=..%5c..%5c..%5cwindows%5cwin.ini HTTP/1.1 Host: target.com

这里把\做了URL编码%5c，很多开发者只过滤了../的Linux风格，却漏了Windows下的反斜杠路径。一个合格的Web安全测试者，必须同时具备跨平台路径思维。

3.2 从“奇安信代码卫士”看静态代码审计的核心思路

这就要聊到热度词里的“奇安信代码卫士工具下载”了。我们可以不讨论具体某个商业工具的界面，但必须理解它的底层工作逻辑：静态应用程序安全测试（SAST）。

在我负责的项目里，对开发团队交付的源码进行审计是常规动作。代码审计工具的核心在于“数据流分析”——它会把用户可控的输入（Source）到危险函数（Sink）之间的路径画出来，如果这条路径上没有被净化函数（Sanitizer）卡住，就判定为漏洞。

考察代码审计思维，最重要的就是掌握“Source -> Sink”模型。举个实战例子：

$dir = $_GET['dir']; include($dir . "/index.php");

这个$dir就是Source，include就是Sink，中间没有经过任何过滤，这就是一个本地文件包含（LFI）漏洞。在笔试的代码审计大题中，拿到一段几百行的代码，不要逐行看，先找参数入口（request.getParameter、$_GET、$_POST），再看这些参数流向哪些敏感函数（exec、eval、include、query），这样才能在半小时内快速找到“埋点”。

3.3 渗透测试报告怎么写才专业：一份高分答案的拆解

笔试的最后大题，会给你一个目标系统http://test.shop.com，让你围绕其中某个模块写测试过程。我当时的写法基本是下面这个框架，之后在奇安信项目的日常工作中，我也会用这份逻辑去对齐整个部门的报告规范：

1. 测试范围控制：明确目标域名、IP段、测试时间窗口、允许使用的攻击方式（如禁止DoS）。
2. 漏洞概要：以表格形式列出漏洞名称、URL、风险等级、可利用性。
3. 漏洞详情与复现：包含请求包、响应包、影响数据范围。其中关键一段这样写：

漏洞URL：https://test.shop.com/api/user/info参数：userId风险等级：高风险

复现请求：

POST /api/user/info HTTP/1.1 Host: test.shop.com Content-Type: application/x-www-form-urlencoded userId=1' and updatexml(1,concat(0x7e,(select user()),0x7e),1)--+

响应中回显了数据库报错信息，证明存在时间盲注/报错注入风险，可获取数据库用户与版本信息，进而可能导致数据泄露。

4. 修复建议：必须具体到代码层。比如“对userId参数使用PreparedStatement预编译进行参数化查询，严格限制输入为整型数字”。

这整个格式，基本就是从奇安信这类售后项目中提炼出来的GTO（Great Technical Output）标准。你可以发现，它强调的不是“我打进了”，而是“我用什么手段打进了，造成了什么后果，如何修得彻底”。笔试环节能写出这样的报告，比单纯罗列工具名称要加分得多。

4. 实操环节：限时“挖洞”中必须掌握的压箱底能力

笔试中也有类似CTF的实操题，给你一个虚拟的答题环境，你在里面提交flag。如果模拟的是真实业务场景，那答题思路就完全不一样了。

4.1 搭建一个模拟环境，把曾经做过的方法跑一遍

我当时为了复习这类实操题，在本地拿DVWA和sqli-labs又过了一遍。核心是不要浮于表面，要把每个Level的防护原理吃透。

以DVWA中的SQL注入模块为例，Low级别的代码是不带任何过滤的字符串拼接，直接跑：

sqlmap -u "http://192.168.1.100/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=xxxxx; security=low" --batch --dbs

时间关系你可以直接拿到所有库名。但Medium级别使用了mysqli_real_escape_string来转义特殊字符。在实战场地上，这意味着你直接丢一个'进去会被转义成\'，导致闭合失效。这时候，很多新手就卡住了。

解题思路的第一性原理是：单引号被转义后，如果业务本身还使用了数字型参数，那么就不需要字符串闭合，直接以数字结尾。例如id=1 and 1=1，它不需要引号也能参与逻辑运算。Deep下钻一下，当后端对id执行了intval()强转，那么你再传1 and 1=1会被强制变成1，根本没法注入。这时候就要看代码逻辑是不是把所有参数都做了强转，或者是仅对关键词做了正则替换。说到底，实操题拼的是“你能根据响应结果的细微差异，判断出后端代码大概长什么样”的能力。

4.2 绕过WAF的几种“肌肉记忆”

在4月21日那天，有一道实操题让我印象很深，给定了一个请求包，要求把注入payload补全，当时目标在后端做了一些拦截。下面几条思路是我在实战中反复使用的“肌肉记忆”，笔试时直接用上了：

• 大小写变形：如果拦截了select，可以尝试SeLeCt，但如果规则是转小写后匹配，那这招没用；
• 注释符拆分：sel/**/ect，如果后端是直接把关键词过滤为空，那内联注释可以完美绕过；但如果后端是调用了PHP的stripslashes和preg_replace双重过滤，就会失效；
• 编码绕过：对整段payload进行URL编码一次或二次。WAF常见只解码一次，如果你发出去的是%2527，服务器解码一层得到%27，再解码一层得到'，而WAF很可能只解到第一层就不管了。

我当时的答题方式就是在Burp里反复对比编码后的响应，最终确认它支持二次解码，于是构造出id=1%252527%2561nd%25201%253d1这样的嵌套payload，成功绕过。

这类实操题是能练出来的。你要做的不是背payload，而是理解每一层解码、解析逻辑。这样你拿着Burp的Intruder去跑字典时，心里才会有底，也才能在有限的考试时间内找到最稳的一条链。

5. 揭掉滤镜：聊聊天擎这类终端安全在Web实战中意味着什么

热度词里有一大堆关于“奇安信天擎卸载”的搜索，这很能反映实际业务场景。在很多企业里，天擎这类EDR（终端检测与响应）是合规要求必须装上的，它和Web安全工程师的日常工作有着极强的关联。

5.1 为什么“卸载要密码”，以及安全工程师该怎么看这件事

很多人一搜索“奇安信天擎卸载密码”，是想把自己电脑上的客户端强制卸载。但站在一个老安全工程师的角度，我必须说清楚：在企业内网，终端杀软往往是由域控、准入策略统一管理，强制卸载会被后台日志记录，这本身就是一个安全事件。

我经历过一个客户，他们的运维同学因为嫌装了天擎之后内存占用高，直接百度搜“如何绕过密码卸载天擎”，结果把主防服务搞坏了，第二天域内爆发了勒索软件变种，那台机器直接成了突破口。所以如果你在奇安信笔试或面试中提到终端安全管理，千万不要说“怎么绕过它”，而要强调如何在有EDR的环境下，做Web攻击链的收敛。

在攻防演练期间，我们做Web渗透测试，最怕的不是WAF，而是目标的服务器上装了EDR。因为一旦Web shell传上去，文件落地瞬间就会被终端查杀，进程执行也会触发行为监控。这时候你的利用思路必须调整为“内存马”或者“无文件攻击”。这些实战细节，比单纯研究怎么卸载客户端有价值得多。

5.2 终端与Web的联动：做安全的全局视角

笔试中肯定也会考“如果Web服务器被攻破，你作为安全工程师第一反应是什么”。我的答案是“日志分析和扩散控制”。不能只盯着/var/log/nginx/access.log，还要结合终端侧的进程启动时间线。奇安信这类厂商的工程师之所以值钱，就是因为他们能打通“网络层—应用层—终端层”三层数据。

用天擎这类EDR反查溯源也是一样：你在Web层看到某个IP发起攻击，你要去EDR后台查这个IP对应的主机上有没有执行过whoami、有没有创建可疑计划任务，两点连起来才能判断攻击者是否已横向移动。这种能力，在2020年笔试现场未必能做实操验证，但在驻场工作中几乎是每日必修。

5.3 做Web安全测试的底线：合规与合法测试边界

最后关于“删除奇安信”、“强制卸载”这些搜索热词，我多提醒一句：合规永远是第一位的。不管在笔试还是真实项目中，只有你拥有授权，只有测试目标在授权范围内，你才可能动手。如果在没有授权的情况下，为了研究技术去尝试卸载一个企业级终端产品，或者对一个非授权系统做扫描，这属于违规行为。

奇安信这类厂商的岗位招聘，非常看重候选人的职业操守。那天的笔试，其实也嵌入了一道软性题：告诉你一个目标，却让你判断测试范围是否超出授权。这种细腻的合规考量，才是从“脚本小子”进阶到“职业Web安全工程师”的分水岭。

我在实际项目中的体会是，笔试和面试都只是入场券，真正拉开差距的是你在跨层数据联动、漏洞根因复盘和报告规范化这些“软实力”上的积累。4月21日那场考试过去很久了，但如果让我重来一次，我会少刷点工具，多花时间把每一条漏洞的请求包、原理和绕过逻辑手写整理成册，那才是真正能在项目中抗住风险的底气。最后再分享一个小技巧：平时做记录时，尽量用纯文本格式保存带时间戳的请求包和响应包，一旦需要溯源或者复盘，回忆不会骗你。