Shannon扫描器自定义规则：从通用扫描到精准漏洞检测的进阶指南
1. 项目概述：为什么我们需要自定义扫描规则？
在Web应用安全领域，自动化扫描工具是安全工程师和开发者的“瑞士军刀”。Shannon作为一款在ARM架构下备受关注的Web应用安全扫描器，其开箱即用的能力已经相当不错。但如果你只是简单地点击“开始扫描”，然后等待报告，那你可能只发挥了它30%的潜力。我见过太多团队，部署了Shannon，跑了几轮默认扫描，发现要么漏报严重——一些自己知道的高危路径没扫出来；要么误报满天飞——把一些正常的业务接口标记为“SQL注入”，搞得开发团队怨声载道，最后工具被束之高阁。
问题的核心在于“适配”。每个Web应用都是独特的：它可能使用特定的框架（如Spring Boot、Django、Laravel），有自己的一套API设计规范（RESTful、GraphQL），甚至包含大量动态生成的前端路由。Shannon的默认规则集是一个“通用套餐”，它试图覆盖最广泛的攻击面，但无法深入理解你应用的“方言”。自定义扫描规则，就是让你教会Shannon说你的应用的“语言”，让它能更精准、更高效地发现真正属于你系统的安全漏洞。这不仅仅是调几个参数，而是将安全测试从“黑盒盲测”升级为“基于理解的深度评估”的过程。对于任何希望将安全左移、真正提升应用内生安全性的团队来说，掌握这项技能是必经之路。
2. 核心思路：从“盲扫”到“精准打击”的策略转变
2.1 理解Shannon的扫描引擎工作原理
要自定义规则，首先得知道工具是怎么工作的。Shannon的扫描过程可以粗略分为几个阶段：信息收集、爬虫探测、漏洞检测、结果分析。在漏洞检测阶段，它依赖于一个规则库。每条规则本质上是一个“检测逻辑模板”，它定义了：
- 攻击向量（Payload）：发送给目标应用的恶意测试数据，例如
' OR '1'='1。 - 检测位置（Place）：将这个Payload注入到哪里，比如URL参数、HTTP头、POST数据、JSON字段等。
- 判断逻辑（Matcher）：如何分析服务器的响应，来判断攻击是否成功。这可能是检查响应中是否包含特定字符串、响应时间是否异常、状态码是否变化等。
默认规则库包含了成千上万条这样的模板，覆盖了OWASP Top 10等常见漏洞。自定义规则，就是让你能够根据自己应用的特点，去优化这个“模板库”——增加针对性的模板，或者调整现有模板的判断逻辑，减少误判。
2.2 自定义规则的四大应用场景
在实际操作中，我们通常在以下四种场景下需要自定义规则：
- 覆盖特有技术栈漏洞：你的应用使用了某个特定版本的开源组件（如Fastjson 1.2.68），而公共规则库可能没有收录针对该版本确切漏洞的检测规则。你需要根据漏洞详情（CVE编号、利用方式）编写专属检测规则。
- 适配业务逻辑漏洞：这是默认扫描器的盲区。例如，你的电商应用有一个“使用优惠券”的功能，业务逻辑是“同一订单不能叠加使用相同优惠券”。攻击者可能通过篡改请求顺序或参数来绕过。你需要编写规则来模拟这种异常业务流。
- 优化爬虫与探测深度：对于前后端分离（如Vue.js + REST API）或大量使用JavaScript动态加载内容的单页应用（SPA），默认爬虫可能无法发现所有接口。你需要通过自定义爬虫策略（如提供API文档、用户登录后的站点地图）来引导Shannon。
- 降低误报率（白名单机制）：某些正常的应用行为（如搜索接口返回用户输入的内容）可能会被误判为XSS。你可以通过编写“误报排除规则”，告诉Shannon当响应符合某种特征（如特定的响应头、URL模式）时，忽略某类告警。
3. 规则文件解析与基础语法
Shannon的规则通常以YAML或JSON格式存储。我们以更易读的YAML格式为例，拆解一条基础SQL注入规则的构成。
id: sql-injection-generic-detection-001 name: Generic SQL Injection Detection via Error-based author: Shannon-Community severity: high description: 检测通过数据库错误信息反馈的SQL注入漏洞。 requests: - method: GET path: /api/user headers: User-Agent: Shannon-Scanner parameters: - name: id type: query payloads: - "'" - "1' OR '1'='1" - "1 AND 1=1" - "1 AND 1=2" fuzz: true matchers: - type: word words: - "SQL syntax" - "MySQL server version" - "ORA-" - "Unclosed quotation mark" condition: or part: body逐项解析与编写要点：
id&name: 规则的唯一标识和可读名称。id建议采用“漏洞类型-方式-编号”的格式，便于管理。severity: 漏洞严重等级（info,low,medium,high,critical）。这直接影响风险评级和报告优先级。description: 清晰描述规则目的，方便后续维护。requests: 定义HTTP请求。这是一个列表，可以包含多个步骤，用于模拟复杂攻击链。method/path/headers: 定义请求的基本要素。parameters: 定义需要注入的参数。name: 参数名。type: 参数位置，如query(URL参数),body(POST表单),json,header等。payloads:攻击载荷列表。这是规则的核心。上面的例子包含了用于触发数据库错误（'）和布尔逻辑测试（1 AND 1=2）的经典Payload。fuzz: true: 这是一个关键选项。当开启时，Shannon不仅会将Payload原样替换参数值，还会尝试与原始参数值进行组合、编码等“模糊测试”，能发现更多边界情况。
matchers:匹配器列表，定义如何判断漏洞存在。type: word: 表示通过关键词匹配。words: 要匹配的关键词列表。这里列出了几种常见数据库的错误信息特征。condition: or: 表示匹配列表中任意一个关键词即算成功。part: body: 在响应的正文（Body）中查找。
实操心得一：Payload的设计艺术不要只堆砌网上找来的Payload字典。有效的Payload设计需要理解漏洞原理。对于SQL注入，应覆盖：错误触发（
',",\）、布尔逻辑（AND 1=1,AND 1=2）、时间盲注（SLEEP(5)）、联合查询（UNION SELECT）等不同类型。对于XSS，则要区分反射型（在<script>alert(1)</script>）和存储型（可能需要多步请求）。最好的方法是结合漏洞原理和目标的常见技术栈（如MySQL、PostgreSQL）来构造针对性Payload。
4. 高级规则编写：处理复杂场景
4.1 多步骤攻击（业务逻辑漏洞检测）
检测业务逻辑漏洞往往需要模拟用户完整的操作流程。例如，检测“越权访问用户订单”：
id: business-logic-unauthorized-order-access-001 name: Vertical Privilege Escalation on Order API severity: high requests: # 步骤1：以低权限用户A登录，并获取其订单ID - method: POST path: /login body: '{"username":"user_a","password":"pass_a"}' matchers: - type: word name: login_success words: - "auth_token" part: body extractors: - type: json name: auth_token json: - .token - type: json name: order_id_a json: - .orders[0].id # 步骤2：使用用户A的token，尝试访问用户B的订单ID（假设通过其他途径已知B的订单ID为1001） - method: GET path: /api/orders/1001 headers: Authorization: Bearer {{auth_token}} # 使用上一步提取的token matchers: - type: status status: - 200 condition: and - type: word words: - "Order details" - "1001" condition: and part: body关键点解析：
extractors（提取器）: 在第一步的matchers之后，我们定义了extractors，用于从响应中提取动态数据（如auth_token,order_id_a）。这些数据会被存储在变量中供后续步骤使用。- 变量引用：在第二步的
Authorization头里，我们使用{{auth_token}}语法引用了第一步提取的变量。这是实现有状态、多步骤测试的核心。 - 判断逻辑：第二步的
matchers要求状态码为200并且响应体包含订单信息，才判定为越权漏洞成功利用。
4.2 使用DSL（领域特定语言）进行复杂匹配
对于更复杂的响应判断，简单的关键词匹配可能不够。Shannon通常支持一种DSL来编写判断逻辑。
假设我们需要检测一个响应时间延迟的盲注漏洞（Time-based Blind SQLi）：
matchers: - type: dsl dsl: - "duration >= 5000" # 响应时间大于5秒 - "status_code == 200" # 且状态码为200 - "contains(body, 'processing')" # 且响应体包含'processing'字样 condition: and或者，检测一个响应内容与原始请求存在差异的漏洞：
matchers: - type: dsl dsl: - "len(body) != len(original_body)" # 当前响应体长度与原始请求响应长度不同 - "!contains(all_headers, 'X-Custom-Error')" # 并且响应头中不包含自定义错误头 condition: and实操心得二：提取器（Extractor）的灵活运用提取器不仅能拿token和ID，还能用于解决会话依赖、验证码旁路（如果响应中有答案）等复杂场景。
json提取器最常用，还有regex（正则）、xpath（HTML/XML）等类型。务必在编写规则前，先用Burp Suite或浏览器开发者工具仔细分析应用的真实流量，准确找到需要提取的数据路径。一个常见的坑是：提取路径写错了，导致后续步骤变量为空，整个规则失效。
5. 规则优化与性能调优
编写规则不是一劳永逸的，需要在实际扫描中迭代优化。
5.1 精准定位，减少无效请求
默认情况下，Shannon会对所有参数进行测试。但有些参数可能不是用户可控的（如时间戳、加密签名）。你可以通过规则中的parameters部分精确指定需要测试的参数名，或者使用attack字段（如attack: body）来指定整个请求体作为攻击位置。
更有效的方式是利用Shannon的“资源标识”功能。你可以在规则中定义target，将规则仅应用于特定的URL路径模式（如/api/*）、特定的文件扩展名（如*.action）或特定的内容类型（如application/json）。这能极大减少对静态资源、图片等无关路径的扫描，提升效率。
5.2 设置合理的速率限制与敏感度
在规则中或全局配置中，可以设置：
threads: 并发线程数。对于生产环境扫描，建议从较低值（如5）开始，避免对服务造成压力。rate-limit: 每秒请求数限制。max-size: 扫描响应的最大尺寸，避免下载大文件。timeout: 单个请求超时时间。
对于matchers，可以调整其敏感度。例如，对于“反射型XSS”检测，如果匹配到Payload出现在响应中，但出现的位置是在HTML注释<!-- -->或JavaScript字符串常量中，则实际不可利用。你可以通过更精细的DSL规则来排除这些情况，或者通过调整规则的severity为low或info，并在后续人工复核。
5.3 规则管理与测试
- 建立规则仓库：不要把所有自定义规则都堆在一个文件里。建议按漏洞类型（
sqli/,xss/,business-logic/）或按应用模块（user-module/,order-module/）分目录存放。 - 版本控制：使用Git等工具管理规则文件，便于回溯、协作和审计。
- 测试环境验证：绝对禁止直接将未经验证的规则用于生产环境扫描。应在与生产环境相似的测试环境或沙箱中，对目标应用进行小范围扫描测试。
- 验证有效性：确保规则能正确触发已知漏洞（可以故意在测试环境留一个）。
- 验证安全性：确保规则不会对应用造成破坏性影响（如重复提交订单、删除数据）。
- 评估性能影响：观察扫描期间的CPU、内存和网络IO。
6. 集成与自动化：让规则持续生效
自定义规则的价值在于持续集成到开发和安全流程中。
- CI/CD流水线集成：在Jenkins、GitLab CI或GitHub Actions中，将Shannon扫描作为一个环节。将你的自定义规则目录作为扫描配置的一部分。可以设置门禁，例如：发现
critical或high级别的新漏洞则阻断流水线。 - 与缺陷管理系统联动：配置Shannon，使其在发现漏洞时，能自动在Jira、禅道等系统中创建工单，并附上详细的请求/响应证据，指派给相应的开发负责人。
- 定期规则更新与维护：
- 同步社区规则：关注Shannon官方或安全社区的规则更新，定期将通用性强的规则合并到你的库中。
- 内部复盘更新：每次真实漏洞被修复后，复盘该漏洞的检测过程。如果现有规则未能发现，则补充或优化规则；如果产生了误报，则添加排除条件。
- 废弃规则清理：随着应用迭代，一些针对旧接口或旧组件的规则可能不再适用，定期清理以避免干扰。
7. 常见问题与排查实录
在实际配置和扫描过程中，你肯定会遇到各种问题。下面是我踩过的一些坑和解决方案。
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
| 扫描结果为空，未发现任何接口 | 1. 目标需要登录，但未配置有效会话。 2. 目标为SPA应用，爬虫无法解析JS。 3. 网络不通或防火墙拦截。 | 1.配置认证：在Shannon中提供登录请求的抓包数据（如Burp的HTTP raw请求），或使用--cookie、--header参数添加有效会话。2.提供站点地图：使用 --list参数提供一个包含所有已知API端点的URL列表文件。3.使用主动爬虫代理：配置浏览器通过Shannon的代理进行手动浏览，让其记录所有流量。 |
| 误报率极高 | 1. 规则匹配条件过于宽松。 2. 应用对错误有统一包装，返回固定信息。 3. 扫描触发了WAF/IPS的拦截页面。 | 1.收紧matchers：将condition: or改为and，增加匹配条件（如特定状态码、响应头）。使用DSL编写更精确的逻辑。2.添加排除规则：编写 matchers-negative（负向匹配器），当响应包含“系统繁忙”、“参数错误”等通用错误信息时，排除该结果。3.识别WAF特征：分析拦截页面的特征（如特定 Server头、Set-Cookie、页面内容），在规则中将其加入排除列表。 |
| 扫描速度极慢 | 1. 并发线程数过高被目标限流。 2. 规则中包含了大量耗时的Payload（如时间盲注的 sleep）。3. 扫描目标响应慢。 | 1.调整速率限制：降低--rate-limit和--threads参数。2.优化规则集：将时间盲注等耗时检测规则单独归类，在深度扫描阶段使用，而非在初扫阶段使用。 3.分阶段扫描：先进行快速的信息收集和爬虫，再对高风险路径进行深度漏洞检测。 |
| 自定义规则未生效 | 1. 规则文件语法错误（YAML缩进、格式）。 2. 规则文件未放在Shannon的正确加载路径。 3. 规则ID冲突。 | 1.语法检查：使用YAML Linter在线工具检查文件格式。 2.路径确认：查阅Shannon文档，确认自定义规则的加载目录（通常是 ~/.shannon/rules/或通过--rules参数指定）。3.查看日志：运行Shannon时添加 -v或--debug参数，查看规则加载日志，确认你的规则是否被成功解析。 |
| 扫描导致测试环境服务异常 | 1. Payload过于激进，导致数据库锁表或服务崩溃。 2. 对写操作接口（POST/PUT/DELETE）进行了测试，产生了脏数据。 | 1.使用“安全”模式：Shannon通常有--safe或--read-only模式，避免测试POST等非幂等方法。2.精确配置Scope：通过 --scope或--include参数严格控制扫描范围，排除管理后台、数据操作接口等危险路径。3.在沙箱环境测试：首次运行新规则集，务必在完全隔离的沙箱环境进行。 |
最后的叮嘱：平衡的艺术自定义扫描规则是一项需要持续投入和打磨的工作。它没有银弹，核心在于平衡：在覆盖率和精准度之间平衡，在扫描深度和性能影响之间平衡，在自动化效率和人工复核必要性之间平衡。我的建议是，从一个具体的小目标开始——比如为你最核心的登录API编写一条防撞库检测规则。成功之后，再将经验复制到其他模块。逐渐地，你会积累起一个高度定制化、与你的应用血脉相连的规则库，它将成为你应用安全体系中真正可靠的一道自动化防线。记住，工具是死的，人是活的，最大的漏洞永远是“配置错误”和“使用不当”。