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 11。检测位置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 11 - 1 AND 11 - 1 AND 12 fuzz: true matchers: - type: word words: - SQL syntax - MySQL server version - ORA- - Unclosed quotation mark condition: or part: body逐项解析与编写要点idname: 规则的唯一标识和可读名称。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 12的经典Payload。fuzz: true: 这是一个关键选项。当开启时Shannon不仅会将Payload原样替换参数值还会尝试与原始参数值进行组合、编码等“模糊测试”能发现更多边界情况。matchers:匹配器列表定义如何判断漏洞存在。type: word: 表示通过关键词匹配。words: 要匹配的关键词列表。这里列出了几种常见数据库的错误信息特征。condition: or: 表示匹配列表中任意一个关键词即算成功。part: body: 在响应的正文Body中查找。实操心得一Payload的设计艺术不要只堆砌网上找来的Payload字典。有效的Payload设计需要理解漏洞原理。对于SQL注入应覆盖错误触发,,\、布尔逻辑AND 11,AND 12、时间盲注SLEEP(5)、联合查询UNION SELECT等不同类型。对于XSS则要区分反射型在scriptalert(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 SQLimatchers: - 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正则、xpathHTML/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编写一条防撞库检测规则。成功之后再将经验复制到其他模块。逐渐地你会积累起一个高度定制化、与你的应用血脉相连的规则库它将成为你应用安全体系中真正可靠的一道自动化防线。记住工具是死的人是活的最大的漏洞永远是“配置错误”和“使用不当”。