xray被动扫描器实战：部署配置、联动AWVS与漏洞验证-平芜编程栈

1. 项目概述：为什么我们需要一个“被动”的扫描器？

在Web安全测试的日常工作中，我们常常面临一个两难的选择：是使用功能强大但可能“动静”太大的主动扫描器，还是选择更隐蔽但功能有限的代理工具？主动扫描器（比如大家熟知的AWVS、Nessus）会主动向目标发送大量精心构造的请求包，试图触发漏洞。这种方式效率高，覆盖面广，但缺点也很明显——它会在目标服务器的日志里留下大量异常请求记录，极易触发告警，甚至可能因为请求过于密集而影响目标服务的正常运行。对于需要隐蔽进行的渗透测试、红队评估或者对生产环境的灰度安全检查，这种“狂轰滥炸”式的扫描显然不太合适。

这时，“被动扫描器”的价值就凸显出来了。它就像一个安静的观察者，不主动出击，而是守在你设定的“流量通道”旁，仔细分析所有经过的HTTP/HTTPS请求和响应。你正常浏览网站、点击链接、提交表单，这些流量都会被它捕获并深度分析。它从这些“正常”的交互中，寻找潜在的安全漏洞，比如未经验证的重定向、不安全的Cookie属性、信息泄露的响应头、潜在的XSS或SQL注入点等。xray正是这样一款设计精良的国产被动Web漏洞扫描器，它以其高性能、低误报率和灵活的部署方式，在安全圈内获得了不错的口碑。

简单来说，你可以把xray理解为你浏览器和互联网之间的一个“智能安检仪”。所有进出的“包裹”（网络流量）都会经过它，它利用内置的强大规则引擎，快速判断这些“包裹”里是否藏有危险品（安全漏洞）。对于安全工程师、渗透测试人员甚至开发人员来说，掌握xray意味着你拥有了一种高效、低调的自动化安全检测能力，可以无缝集成到你的日常测试流程中，无论是手动测试的辅助，还是与自动化工具链的联动，都能显著提升发现漏洞的效率和深度。

2. 核心思路与部署方案选型

配置和使用xray，核心思路在于如何将它巧妙地“嵌入”到你的网络流量路径中，并让它能“看懂”经过的流量。这通常涉及到代理的配置。xray本身支持多种工作模式，但对于被动扫描而言，最常用的是启动一个上游HTTP代理。你的浏览器或其他客户端工具将流量发送给xray代理，xray在转发流量的同时进行分析。

2.1 部署模式解析

根据测试场景和复杂度的不同，主要有以下几种部署方案：

单机本地代理模式：这是最快速的上手方式。直接在本地计算机上启动xray，并配置浏览器使用xray监听的端口作为代理。所有通过该浏览器的流量都会被xray分析。适合个人学习、对单个Web应用进行手动安全测试。
反向代理模式：将xray部署在一台独立的服务器（如测试环境中的跳板机）上，让它作为后端Web服务器的反向代理。所有指向目标应用的流量都先经过xray。这种方式适合测试移动端App、或者需要对一个完整服务入口进行无感扫描的场景。
流量镜像模式：在一些复杂的网络架构中，可以通过端口镜像（SPAN）或分光的方式，将生产环境的流量复制一份发送到xray所在的服务器进行分析。这是一种完全无侵入的监控方式，适用于对线上业务进行持续的安全监控，但需要网络设备的支持。
与主动扫描器联动模式：这也是一个非常经典的用法。利用xray的“扫描插件”功能，它可以接收来自其他工具（如AWVS、Burp Suite）的主动扫描请求和响应，并进行被动分析。这样，你可以在使用AWVS进行主动深度扫描的同时，让xray从另一个角度（被动规则）分析同样的流量，实现漏洞覆盖的互补。

对于大多数从入门到实战的用户，我建议从模式1和模式4开始。模式1能让你最快地理解xray的工作原理和效果；模式4则能极大提升你现有工具链的威力，是实战中性价比极高的选择。

2.2 工具链搭配考量

为什么强调与AWVS等工具联动？因为工具各有侧重。AWVS的主动扫描引擎在爬虫、漏洞检测逻辑方面非常强大，尤其擅长发现复杂的业务逻辑漏洞和需要深度交互才能触发的漏洞。而xray的被动扫描规则，对一些基于上下文、响应特征的漏洞（如JSONP劫持、SSRF的特定响应、敏感信息泄露）有独特的检测优势。两者结合，相当于给你的安全检测上了“双保险”。

在工具选型时，还需要考虑xray的规则更新。xray社区版拥有一个活跃的规则库，会持续更新。这意味着即使你不懂编写复杂的POC，也能依靠社区的力量检测到最新的漏洞类型。这是选择xray的一个重要理由——它降低了持续维护检测能力的成本。

3. 从零开始：xray的安装与基础配置

3.1 获取与安装

xray是跨平台的，支持Windows、macOS和Linux。官方提供了编译好的可执行文件，下载解压即可使用，无需复杂的编译环境。这是它友好的一面。

访问官方发布页面：前往xray的GitHub releases页面，根据你的操作系统下载最新的稳定版。例如，对于64位Linux系统，就下载xray_linux_amd64.zip。
解压与准备：将下载的压缩包解压到一个你喜欢的目录，比如/opt/xray/或C:\Tools\xray\。解压后你会看到几个关键文件：
- xray或xray.exe：主程序。
- config.yaml：配置文件模板。
- *.yaml：各种模块的配置文件，如plugins.yaml（插件配置）。
赋予执行权限（Linux/macOS）：在终端中，进入xray所在目录，执行chmod +x xray。

注意：由于安全工具的敏感性，请务必从官方或可信渠道下载，避免使用来历不明的版本，以防内置后门。

3.2 首次运行与生成配置文件

xray的强大和灵活很大程度上体现在其配置文件上。我们首先来生成一份完整的配置。

在命令行中，进入xray所在目录，执行以下命令：

# Linux/macOS ./xray genca # Windows xray.exe genca

这个命令会做两件事：

在当前目录生成一个默认的config.yaml主配置文件。
生成一套自签名的CA证书（ca.crt和ca.key），用于对HTTPS流量进行中间人（MITM）解密分析。这是被动扫描能分析加密流量的关键。

接下来，我们启动xray进行最简单的测试：

./xray webscan --listen 127.0.0.1:7777 --html-output report.html

这个命令启动了xray的Web扫描模块，并告诉它：

--listen 127.0.0.1:7777：在本地回环地址的7777端口启动一个HTTP代理服务器。
--html-output report.html：将扫描结果实时输出到report.html文件。

现在，打开你的浏览器（以Firefox为例），配置手动代理：HTTP代理为127.0.0.1，端口7777。然后访问任何一个HTTP网站。你会发现xray的命令行窗口开始输出日志，访问结束后，当前目录下会生成一个report.html文件，用浏览器打开它，就能看到xray分析出的潜在问题，比如缺少安全头的警告等。

3.3 核心配置文件解析

直接使用命令行参数虽然快捷，但功能有限。要发挥xray的全部能力，必须理解和配置config.yaml。这个文件结构清晰，我们挑几个实战必改的模块讲。

mitm 配置段：这是中间人攻击（解密HTTPS）的核心。

mitm: restriction: includes: # 只对哪些域名进行MITM解密和扫描？建议明确指定，避免隐私泄露和不必要的流量。 - “*.example.com“ # 例如，只扫描example.com及其子域名 - “testapp.local“ excludes: # 排除哪些域名？常用于排除第三方资源（如CDN）或登录认证等关键页面，避免干扰。 - “*.google.com“ - “*.gstatic.com“ ca_cert: /opt/xray/ca.crt # CA证书路径 ca_key: /opt/xray/ca.key # CA私钥路径

plugins 配置段：控制启用哪些扫描插件。xray的漏洞检测能力以插件形式存在。

plugins: cmd_injection: # 命令注入插件 enabled: true # 可以在这里配置插件特定参数，如检测深度 sqldet: # SQL注入检测插件 enabled: true xss: # 跨站脚本插件 enabled: true baseline: # 基线检查插件（检查安全头、Cookie等） enabled: true dirscan: # 目录扫描插件（被动发现敏感目录） enabled: false # 被动模式下，目录扫描效果有限，通常关闭

reverse 配置段：用于检测需要服务器回连的漏洞，如SSRF、Fastjson反序列化等。这是高级功能，需要你有一个公网IP或使用类似ngrok的服务做内网穿透。

reverse: db_file_path: “./reverse.db“ # 数据库文件路径 token: “your_random_token_here“ # 客户端连接令牌，需保密 http: enabled: true listen_ip: 0.0.0.0 listen_port: 80

配置完成后，使用配置文件启动xray：

./xray webscan --config config.yaml

4. 实战进阶：与AWVS联动实现“动静结合”

这是将xray威力倍增的经典用法。AWVS在主动扫描时，会产生大量请求和响应。我们可以让xray监听一个端口，然后将AWVS的扫描目标通过这个端口代理出去。这样，AWVS的每一个主动探测请求和对应的响应，都会被xray捕获并进行被动规则分析。

4.1 配置xray为带外扫描服务器

首先，我们需要修改xray配置，使其不仅能做普通代理，还能接受来自扫描器的“推送”流量。这需要用到scan_port配置。

在config.yaml的webscan部分（或主配置层级），添加或修改：

webscan: proxy: # 上游代理设置（如果你需要xray本身也通过一个代理上网，可以在这里配置） mitm: ... # 之前的mitm配置 plugins: ... # 之前的插件配置 scan_port: 10086 # 新增：开启一个额外的端口，专门用于接收扫描器推送的流量

然后启动xray：

./xray webscan --config config.yaml

此时，xray会监听两个端口：一个是MITM代理端口（默认在配置中指定或通过--listen设置），另一个就是我们刚设置的10086端口。

4.2 配置AWVS发送流量到xray

在AWVS中创建新的扫描目标。
在扫描设置的“Network”或“Advanced”部分，找到配置HTTP代理的地方。
将代理设置为http://127.0.0.1:10086（假设xray和AWVS在同一台机器上）。
开始扫描。

现在，AWVS发出的所有扫描请求，都会先被发送到xray的10086端口。xray不会转发这些请求（因为它不是普通代理），而是直接分析请求和响应内容，应用其被动扫描规则。AWVS则像什么都没发生一样，继续它的主动扫描流程。你会在xray的控制台看到它正在分析来自AWVS的流量，并最终在report.html或你配置的其他输出中，看到它独立发现的漏洞报告。

4.3 联动模式的优势与注意事项

优势：

漏洞覆盖更全面：AWVS可能漏报的某些基于响应特征的漏洞，xray可能抓到。
资源利用率高：一次扫描，两份报告，不增加额外的网络请求负担（xray只分析，不主动发包）。
隐蔽性依旧：对于目标服务器而言，它只看到了AWVS的扫描流量（这本身可能就不隐蔽），xray的分析过程是完全后台的。

注意事项：

去重：同一个漏洞点，AWVS和xray可能都会报告，需要人工进行合并和去重。
性能：如果AWVS扫描速度极快，产生海量请求，可能会对xray的分析性能造成一定压力。可以适当调整xray的并发分析线程数（在配置文件中）。
配置隔离：确保AWVS扫描的域名在xray的mitm.restriction.includes范围内，否则xray不会分析这些流量。

5. 扫描结果分析与漏洞验证

xray默认的HTML报告已经非常直观，它会按风险等级（Critical, High, Medium, Low, Info）对发现的问题进行分类。每一条记录都包含了：

漏洞类型：如SQL Injection,XSS,Info Leakage。
目标URL：发现问题的具体地址。
请求与响应：可以展开查看触发该告警的原始HTTP请求和响应详情，这是手动复现和验证的关键。
Payload：xray检测时使用的payload或触发的条件。

切记，工具的报告只是“线索”，不是“判决书”。尤其是中低危的发现，误报率是存在的。安全工程师的核心价值之一，就是对这些线索进行人工研判和验证。

验证流程建议：

理解告警原理：点击报告中的漏洞类型，通常会链接到详细的说明文档，了解xray是基于什么规则判断的。
复现HTTP请求：使用Burp Suite Repeater、Postman或cURL，将xray报告中提供的原始请求原样重放一次，观察响应。
手动构造POC：根据漏洞类型，尝试手动构造更确凿的证明。例如，对于疑似SQL注入的点，尝试插入sleep(5)等时间盲注的payload，观察响应延迟。
评估实际影响：即使漏洞存在，也需要评估其实际可利用性和对业务的影响程度。一个需要复杂条件才能触发的存储型XSS，和一个反射型XSS，风险等级是不同的。

对于xray报告的高危漏洞（如明确的命令注入、SQL注入回显），也要谨慎验证，避免测试请求对生产数据造成破坏。最好在测试环境或获得明确授权的前提下进行。

6. 性能调优与高级技巧

当扫描大型应用或使用联动模式时，可能会遇到性能瓶颈。以下是一些调优点：

并发控制：在config.yaml中，可以调整max_parallel参数，控制并发分析的任务数。根据机器CPU和内存情况调整，通常设置为CPU核心数的2-4倍。
内存限制：xray默认会缓存一定量的请求/响应进行分析。对于超长会话（如扫描一个包含大量步骤的Web流程），可能占用较多内存。可以关注max_resp_body_size等参数，限制分析单个响应的大小。
精准的目标范围：务必用好mitm.restriction.includes。只包含你需要扫描的域名。这不仅关乎隐私和合规，也能大幅减少xray需要处理的无用流量，提升分析效率和准确性。
插件选择性启用：如果你明确知道目标应用的技术栈（比如是纯前端React应用，没有Java），可以关闭一些不相关的插件，如struts,thinkphp等，减少规则匹配开销。
使用反连平台（Reverse）：对于SSRF、Fastjson、Log4j2这类需要目标服务器主动连接出来才能确认的漏洞，搭建一个xray反连平台是质变。你需要一个具有公网IP的服务器，或者使用ngrok/frp等工具将内网端口暴露出去。配置好reverse段后，xray会在payload中插入你的反连平台地址，一旦漏洞被触发，目标服务器会尝试连接你的平台，从而被xray捕获并确认漏洞。这是证明“漏洞真实存在”的强力证据。

7. 常见问题与排查实录

在实际使用中，你肯定会遇到各种问题。这里记录几个最典型的：

问题1：配置了代理，但xray没有捕获到任何流量，报告为空。

排查思路：
1. 检查代理配置：确认浏览器或客户端工具正确配置了xray的代理地址和端口。在浏览器中访问http://burp或类似地址，看xray是否有连接日志。
2. 检查防火墙：确保本地防火墙没有阻止xray监听端口。
3. 检查HTTPS解密：如果是HTTPS网站，需要在浏览器中安装xray生成的CA证书（ca.crt）。否则浏览器会因证书不被信任而中断连接。安装后，访问一个HTTPS站点，xray应该能输出解密后的域名信息。
4. 检查目标范围：确认你访问的域名在mitm.restriction.includes列表中，且不在excludes列表中。

问题2：与AWVS联动时，xray没有收到流量。

排查思路：
1. 确认scan_port：确保xray配置中正确开启了scan_port，并且AWVS配置的代理端口与之对应。
2. 查看xray日志：启动xray时加上--debug参数，查看是否有来自AWVS IP的TCP连接建立。
3. 检查AWVS代理设置：确认AWVS的代理设置已保存并生效，有些版本的AWVS代理设置可能分全局和扫描单独设置。

问题3：扫描报告误报太多，尤其是“信息泄露”类。

分析与处理：被动扫描的误报，尤其是基线检查（baseline）插件产生的，很多时候是因为规则比较严格。例如，它可能认为任何包含“内部IP”或“邮箱”的响应都是信息泄露。你需要：
1. 审查规则：了解具体是哪条规则触发的。
2. 调整插件配置：有些插件允许配置更精细的过滤规则，比如忽略特定路径下的特定关键字。
3. 人工研判：将误报归类，如果发现是某一类固定误报（如某个第三方组件返回的固定信息），可以考虑将该URL路径加入mitm.restriction.excludes，或者后续在报告分析时直接过滤。

问题4：xray进程占用内存或CPU过高。

处理方案：
1. 限制目标范围：这是最有效的方法。
2. 调整并发数：降低max_parallel。
3. 升级硬件：xray分析很吃CPU单核性能和多核并行能力，使用性能更强的机器。
4. 分而治之：对于超大型应用，可以按功能模块分多次扫描，每次修改includes列表。

配置和使用xray的过程，是一个不断“磨合”的过程。你需要了解它的脾气（规则特性），清楚你的目标（测试范围），才能让它成为你得心应手的助手，而不是一个制造噪音的麻烦。从最简单的本地代理开始，逐步尝试联动扫描，再到搭建反连平台进行深度检测，每一步都能让你对Web应用的安全状态有更立体、更深入的了解。工具永远在迭代，但通过工具培养出的流量分析思维、漏洞验证方法和安全工程体系，才是更宝贵的财富。