1. 项目概述为什么AWVS自定义规则是电商安全审计的“放大镜”做电商安全渗透测试的朋友估计对AWVSAcunetix Web Vulnerability Scanner都不陌生。它是个老牌的全自动Web漏洞扫描器开箱即用内置的策略库对付常见漏洞像SQL注入、XSS效率很高。但这些年我经手过不少电商项目发现一个普遍现象那些真正能造成业务损失、数据泄露的“硬茬子”漏洞往往不是OWASP Top 10里的标准题型而是深深嵌在业务逻辑里的“隐藏漏洞”。比如一个看似正常的商品价格篡改、一个隐蔽的优惠券无限领取逻辑、或者一个用户会话在特定操作序列下的异常保持。这些漏洞AWVS的默认策略库经常“视而不见”。这就是我们今天要聊的核心AWVS的自定义扫描策略与规则。你可以把它理解成给AWVS这个“标准流水线工人”配上了一副“业务特制放大镜”。默认策略是通用工具而自定义规则则是针对你当前扫描的电商网站量身定制的“探测针”。它能教会扫描器去关注那些标准测试用例覆盖不到但对你目标系统至关重要的业务接口、参数和逻辑路径。通过编写自定义的“Form Rules”表单规则和“Per Directory/Per Host Rules”目录/主机规则我们能引导AWVS对特定功能点如购物车、订单提交、支付回调、会员中心进行更深、更巧妙的探测从而揪出那些隐藏在复杂业务交互背后的安全风险。简单说这个项目就是一次从“泛泛而扫”到“精准打击”的升级。它适合已经熟悉AWVS基础操作的安全工程师、渗透测试人员以及需要为自家电商平台做深度安全体检的开发或运维同学。如果你已经厌倦了扫描报告里一堆无关紧要的低危信息想真正找到能“一招致命”的业务逻辑漏洞那么掌握这套方法会让你在安全审计中的效率和深度提升一个档次。2. 核心思路与策略设计从“漫无目的”到“有的放矢”在动手写任何一条规则之前最关键的一步是策略设计。你不能指望漫无目的地添加几条规则就能有奇效。整个自定义扫描的成败七分靠策略设计三分靠规则编写。2.1 目标分析与攻击面测绘首先你得忘掉扫描器像攻击者一样思考。针对一个电商网站它的核心攻击面在哪里用户身份与认证体系注册、登录、密码找回、短信/邮箱验证码、会话管理。这里可能存在的隐藏漏洞包括验证码可爆破、登录后会话可并行登录、密码重置链接可预测或未绑定用户。商品与交易流程商品详情页、加入购物车、修改购物车商品数量或属性、提交订单、选择支付方式、支付状态回调。这里容易滋生业务逻辑漏洞比如负数价格、超库存购买、优惠券叠加逻辑错误、支付金额篡改、订单状态未验证。用户数据与功能个人资料修改、收货地址管理、订单列表与详情、余额/积分变动、优惠券领取与使用。这里可能存在越权访问水平/垂直、CSRF、信息泄露等。后台与管理接口虽然通常权限较高但有时会存在未授权访问、弱口令或者前端API路由配置错误导致后台接口意外暴露。第三方集成点支付网关回调、物流查询接口、短信/邮件发送接口。这些往往是安全盲区可能存在参数注入、SSRF服务器端请求伪造或逻辑缺陷。我的习惯是在扫描开始前先用浏览器手动走一遍核心业务流程同时用Burp Suite这类代理工具抓取所有HTTP请求。把抓到的请求按功能模块分类保存特别关注那些包含敏感操作增删改查状态、涉及金钱的POST请求和带有复杂参数的GET请求。这份“请求地图”就是你编写自定义规则的“靶心”。2.2 自定义策略的构成与定位AWVS的自定义策略主要围绕两个核心展开输入点探测和攻击载荷投递。输入点探测Finding Inputs这是扫描的第一步。AWVS需要知道往哪里注入测试载荷。默认情况下它会自动解析HTML表单、URL参数、Cookie、HTTP头等。但对于一些动态生成的内容、复杂的JSON API、或者非标准的参数格式它可能识别不全。这时就需要“Per Directory/Host Rules”或“Form Rules”来明确告诉扫描器“嘿这个/api/v1/order/submit接口的请求体是JSON格式其中items[0].price和totalAmount是重要的数字型参数请重点测试它们。”攻击载荷投递Attack确定了输入点就要决定用什么“炮弹”去测试。AWVS内置了大量攻击载荷如各种SQL注入语句、XSS向量。自定义规则在这里的作用是增强和聚焦。例如针对电商的价格参数我们可以自定义一批测试“负数”、“超大数”、“小数”、“0”的载荷针对优惠券码我们可以自定义一批测试“重复使用”、“与其他优惠叠加”逻辑的载荷。一个完整的自定义扫描策略就是由一系列这样的“探测指令”和“攻击配方”组合而成形成一个针对特定目标的、高度定制化的测试方案。2.3 工具选型与前期准备工欲善其事必先利其器。除了AWVS本体我强烈建议搭配以下工具协同工作代理抓包工具Burp Suite Professional / OWASP ZAP用于手动探索网站捕获和分析HTTP/S请求/响应是分析攻击面、制定规则不可或缺的。社区版Burp或ZAP免费版也足够用。浏览器开发者工具F12用于快速分析前端代码、网络请求和本地存储LocalStorage, SessionStorage常能发现一些API端点或隐藏参数。文本编辑器/IDE用于编写和修改自定义规则文件通常是XML格式。有语法高亮会更方便。测试环境绝对不要在未经授权的生产环境上进行扫描务必准备一个与生产环境代码一致的测试环境Staging、或者使用合法的漏洞演练平台如DVWA、WebGoat或专门的电商演练项目。这是安全测试的道德和法律底线。准备好这些我们的“作战地图”和“武器装备”就齐全了可以开始进入具体的规则编写环节。3. 核心规则解析与编写实战AWVS的自定义规则主要通过其“Custom Scan Policies”功能实现核心是编辑一个XML格式的策略文件。下面我们以电商场景为例拆解几种最常用、最有效的规则类型。3.1 Form Rules精准制导的“表单轰炸机”Form Rules表单规则用于精确定义如何扫描一个特定的HTML表单或类似表单的请求如JSON API。当AWVS的爬虫或你手动提交的请求中发现匹配的规则时就会按照你的定义进行深度测试。实战案例电商订单提交接口漏洞挖掘假设我们分析订单提交接口POST /checkout/order其请求体可能是JSON格式{ items: [ {id: 123, qty: 2, price: 59.99} ], couponCode: SAVE10, shippingId: 5, totalAmount: 119.98 }默认扫描可能只把整个JSON体当作一个字符串参数来测试效果很差。我们需要写一个Form Rule来精细化测试。规则编写思路与步骤定位目标Match规则首先要能匹配到这个请求。我们可以用URL路径/checkout/order和请求方法POST来定位。定义输入点Inputs告诉AWVS在这个JSON里items[0].price、qty、couponCode、totalAmount都是需要单独测试的参数。并且要指定它们的类型IntegerString,Decimal。定制攻击Attacks - 可选但重要对于price和totalAmount这类金额参数除了通用的SQL注入测试我们更关心业务逻辑漏洞。我们可以创建一个自定义的“攻击类型”比如叫“Business Logic - Price Manipulation”为其配置一套特殊的测试载荷-1,0,0.01,9999999,1.00测试小数处理甚至100-10测试运算表达式是否被执行。一个简化的规则XML结构示意Form Match URL/checkout/order/URL MethodPOST/Method RequestTypeJSON/RequestType /Match Inputs Input nameitems[0].price typeDecimal / Input nameitems[0].qty typeInteger / Input namecouponCode typeString / Input nametotalAmount typeDecimal / /Inputs !-- 可以关联自定义的攻击配置 -- /Form实操心得编写Form Rule时Match部分不要过于宽泛否则规则会应用到不相关的请求上拖慢扫描速度并产生噪音。同时充分利用type字段它能帮助扫描器选择更合适的测试载荷例如对Integer型测试整数溢出对Decimal型测试浮点数精度问题。3.2 Per Directory/Per Host Rules划定重点轰炸区域这类规则用于针对特定目录或主机调整扫描的全局行为。比如对上传目录/uploads/采用更激进的文件内容检测对API接口目录/api/禁用一些无用的HTML解析或者对管理后台/admin/使用更强大的字典进行路径爆破。实战案例针对API接口目录的优化扫描电商网站的/api/v1/目录下全是RESTful API返回的都是JSON/XML没有HTML。AWVS默认的爬虫和解析器会在这里浪费大量时间且可能解析错误。我们可以创建一个Per Directory Rule目标/api/v1/动作Disable Heuristic Links禁用启发式链接发现避免从JSON数据里胡乱猜测链接。Disable Non-parameter based attacks禁用一些非基于参数的攻击如某些目录遍历的启发式测试因为API通常严格依赖参数。可以Enable更深入的JSON/XML Injection测试。设置Custom 404 Signature如果该API有统一的错误响应格式如{error: not_found}可以在这里设置帮助扫描器更准确地识别无效路径提升爆破效率。编写要点这类规则是提升扫描效率的利器。通过为不同功能的目录“因材施教”可以大幅减少无用功把扫描火力集中在正确的方向上。3.3 自定义攻击载荷Custom Attack Patterns这是挖掘“隐藏漏洞”的杀手锏。AWVS允许你为特定的漏洞类型甚至是自己定义的类别创建全新的测试载荷。实战案例设计“优惠券逻辑缺陷”测试载荷电商的优惠券系统逻辑复杂容易出问题。我们可以创建一个名为“Coupon Logic”的攻击类型。分析潜在漏洞点无限使用同一优惠券码多次提交。叠加滥用设计多组测试尝试将“满减券”、“折扣券”、“免邮券”进行非法叠加。条件绕过优惠券有使用门槛如满100可用尝试通过修改购物车金额、拆分订单等方式绕过。归属篡改尝试使用其他用户的专属优惠券码。设计载荷这些漏洞的测试往往不是注入恶意字符串而是构造特定的业务请求序列或参数组合。例如载荷1在同一个会话中对同一个订单ID重复提交包含同一couponCode的请求。载荷2在一个请求中同时提交couponCode1DISCOUNT20和couponCode2FREESHIP。载荷3先添加商品使总额为120元应用“满100减10”券然后在支付前快速请求修改商品数量使总额变为90元观察优惠是否被错误保留。在AWVS中实现你需要通过“Attack Types”配置界面新建一个分类然后手动添加这些“测试用例”。每个用例可能对应一个简单的字符串替换也可能需要配合“Sequences”请求序列功能来实现多步操作。重要提示自定义攻击载荷的成功检测极度依赖你对服务器响应的判断。AWVS需要知道什么样的响应代表“漏洞可能存在”。你需要仔细定义“漏洞特征”Grep比如在响应体中查找“Total amount: -10.00”或“Coupon applied successfully”在非法请求后再次出现。这部分需要结合手动测试的经验来反复调试。4. 完整扫描流程与策略整合有了以上规则我们需要将其整合到一个完整的扫描流程中。AWVS的扫描是分阶段的理解这些阶段有助于我们安排规则的生效时机。4.1 扫描阶段与规则生效时机爬虫阶段CrawlingAWVS探索网站结构和链接。此时Per Directory Rules会生效影响爬虫在特定目录下的行为。Form Rules也会被爬虫发现并注册为后续攻击阶段做准备。攻击阶段AttackAWVS利用爬虫阶段发现的输入点注入攻击载荷进行测试。此时所有定义的Form Rules和自定义攻击载荷会大显身手。特定探测阶段如目录爆破、端口扫描等。Per Directory/Host Rules中关于自定义404、禁用某些探测的配置会在这里起作用。一个推荐的电商扫描策略配置流程如下创建新策略在AWVS的“Scan Policies”中基于“Full Scan”或“Web Application”模板创建一个新策略命名为“E-Commerce Deep Audit”。导入与配置规则将编写好的Form RulesXML文件导入到策略的“Form Rules”部分。在“Per Directory/Host Rules”部分添加针对/api/,/admin/,/upload/,/payment/等目录的优化规则。在“Attack Types”中启用你创建的“Business Logic - Price Manipulation”和“Coupon Logic”等自定义攻击并调高其攻击强度如果策略允许。调整爬虫设置限制爬虫范围避免爬取到无关的第三方域名。针对SPA单页应用网站可能需要启用“Crawl AJAX”和“Parse JavaScript”选项。设置合适的爬虫速度避免对测试服务器造成压力。配置身份认证如果目标网站需要登录务必在“Login”部分正确配置登录序列Record Login Sequence。这是扫描覆盖登录后功能的前提。对于复杂的验证码可能需要手动处理或暂时禁用相关功能进行测试。启动扫描与监控将新策略应用到扫描任务开始扫描。密切关注扫描日志特别是“Alerts”部分看自定义规则是否被成功触发和执行。4.2 策略的调试与优化第一次使用自定义策略扫描很少能一帆风顺。需要反复调试规则未触发检查Match条件是否太严格或太宽松。用AWVS的“HTTP Sniffer”或扫描日志查看爬虫是否发现了目标请求。攻击无效检查自定义攻击载荷的“Grep”设置是否正确。最好先用Burp Suite手动复现一次攻击确认服务器在漏洞存在时的响应特征再将这个特征填入规则。误报率高如果自定义规则产生了大量误报需要细化漏洞判断条件。例如不仅检查响应中是否包含“error”还要检查是否包含特定的错误代码或信息。扫描速度慢检查是否添加了太多宽泛的规则导致扫描器在无关页面上也执行了深度测试。优化Per Directory Rules在非重点区域禁用部分攻击。这个过程就像调教一个AI你需要用清晰的指令规则和正确的反馈调试来让它变得越来越聪明越来越贴合你的目标。5. 典型电商漏洞挖掘案例与规则实现让我们结合几个具体的电商漏洞场景看看如何将分析转化为实际的AWVS规则。5.1 案例一商品价格篡改漏洞漏洞描述在提交订单时前端传递的商品价格item.price或总价totalAmount未被服务器端重新校验攻击者可以修改为任意值如负数、0、极低价格。规则设计要点Form Rule定位匹配订单提交请求如POST /api/order。定义输入识别出价格参数如items[0].price,totalAmount类型设为Decimal。自定义攻击创建攻击类型“Price Tampering”。载荷列表-1,0,0.01,1,9999999,100-90。漏洞特征Grep这是关键。需要定义服务器“中招”后的响应特征。例如成功下单的响应中可能包含status:success和finalPrice:xxx。我们可以在攻击后检查响应中是否包含status:success并且finalPrice的值与我们注入的恶意价格相符或异常低。或者检查响应中是否出现了本应出现的错误信息如price invalid却没有出现。可以设置“差分分析”比较正常请求与恶意请求的响应差异。5.2 案例二优惠券业务逻辑漏洞漏洞描述优惠券可无限次使用、不同优惠券可非法叠加、优惠券使用门槛可被绕过。规则设计要点Form Rule定位匹配应用优惠券的请求如POST /cart/apply-coupon或包含couponCode的订单提交请求。定义输入couponCode字符串类型。自定义攻击 - 更复杂的场景无限使用这通常需要“请求序列Sequence”功能。编写一个序列a) 正常使用优惠券下单b) 使用相同的会话和优惠码再次尝试下单。检查第二次请求是否成功且优惠金额是否被重复扣除。叠加滥用在同一个请求中尝试注入多个优惠券参数如couponCode[]CODE1couponCode[]CODE2或修改参数名为couponCode1,couponCode2。观察总优惠金额是否异常。条件绕过需要与价格篡改结合。先构造一个满足门槛的请求总额100应用优惠券然后在最终提交前在另一个请求中快速修改购物车使总额低于门槛总额90观察订单是否以优惠后的价格成立。漏洞特征关注响应中的discountAmount,totalAfterDiscount等字段数值是否异常。或者检查订单成功创建后优惠券的状态是否仍为“可用”。5.3 案例三水平越权访问用户数据漏洞描述通过修改请求中的用户ID参数如userId123或orderId456可以访问或操作其他用户的数据。规则设计要点识别敏感接口如GET /api/user/profile?id,GET /api/orders/details?orderId。Form Rule定位匹配这些GET请求虽然GET请求默认也会被扫描但自定义规则可以加强。定义输入id,userId,orderId等参数类型为Integer或String。自定义攻击创建攻击类型“IDOR Test”。载荷列表这里不是注入恶意字符串而是替换成“其他可能存在的ID”。可以是一个简单的增量/减量如原ID是100则测试99和101也可以加载一个常见的ID字典文件。漏洞特征这是最需要精细判断的。攻击者自己的ID如100请求会返回自己的数据。我们替换成101后发送请求。如果返回403/404说明访问控制有效安全。如果返回200且响应体结构与之前相似但内容不同如用户名、订单详情变了这就是高危的水平越权漏洞我们需要让AWVS能识别这种“结构相似但内容不同”的响应。这可以通过设置“差分分析”规则来实现比较两个请求响应的相似度并结合响应码判断。技巧为了帮助扫描器可以在扫描前先用两个不同的测试账号登录让AWVS学习到不同用户数据的“正常差异”。这样在测试时它更容易判断访问其他用户ID的响应是否属于“异常访问”。6. 高级技巧、避坑指南与效果评估掌握了基础规则编写后一些高级技巧和实战中的“坑”能让你事半功倍。6.1 高级技巧利用序列Sequences和宏Macros序列Sequences用于测试多步操作才能触发的漏洞。AWVS可以录制并回放一系列请求。例如测试“下单后未支付订单可重复支付”漏洞序列1-添加商品序列2-创建订单序列3-模拟支付请求序列4-重复序列3。通过比较响应来判断漏洞。宏Macros用于处理复杂的会话状态或动态令牌。例如某些操作需要从上一个响应的JSON中提取一个csrf_token或orderToken并填入下一个请求。AWVS的宏可以自动完成这种提取和填充确保多步测试的连贯性。实操心得在配置登录序列Login Sequence或复杂业务宏时务必使用“Test”功能反复验证其可靠性。一个失败的登录宏会导致整个扫描覆盖度归零。同时注意会话Session的处理确保扫描器在整个序列中保持登录状态。6.2 常见问题与排查技巧扫描器登录失败检查登录序列确认用户名/密码正确验证码是否已正确处理测试时最好先禁用。检查会话管理查看扫描请求的Cookie是否在后续请求中正确携带。有时网站使用自定义的Token头如Authorization: Bearer xxx需要在“Session Management”中配置。检查HTTPS证书如果测试环境使用自签名证书需要在AWVS的“Network”设置中导入或忽略证书错误。自定义规则未被触发查看爬虫结果在扫描结果的“Crawl”部分检查目标请求是否被成功爬取到。如果没有可能是爬虫没发现该链接需要检查爬虫设置或手动将该URL添加到扫描范围。检查规则匹配条件规则中的URL匹配是区分大小写和路径的。使用相对路径还是绝对路径是否包含了查询参数最好使用最明确的匹配条件。查看扫描日志AWVS的详细日志会记录规则匹配和攻击执行的过程是排查问题的最佳位置。产生大量误报或漏报误报通常因为“漏洞特征Grep”设置过于宽泛。例如仅凭响应中存在“error”一词就判断为漏洞但正常业务失败也会返回“error”。需要结合更具体的上下文信息错误代码、特定短语来精确定义。漏报可能因为攻击载荷不够全面或漏洞特征定义太严格。建议对疑似漏洞点先用Burp Suite手动构造几个极端测试用例观察响应再将成功的攻击模式“翻译”成AWVS规则。扫描速度异常缓慢检查攻击强度在自定义策略中是否启用了过多攻击类型或设置为“最高强度”这会生成海量测试请求。检查目标服务器响应可能是目标服务器本身响应慢或者触发了WAF/速率限制导致请求被延迟或阻塞。优化扫描范围是否爬取到了无数无关的静态资源链接如图片、CSS并对它们也进行了攻击使用Per Directory Rules在静态资源目录禁用攻击。6.3 扫描效果评估与报告整合一次深度扫描完成后如何评估自定义策略的效果对比分析使用相同的目标分别用“默认Full Scan策略”和你的“电商深度审计策略”进行扫描。对比两份报告。关键指标漏洞数量与等级自定义策略是否发现了更多、更严重特别是High/Critical级别的漏洞漏洞质量发现的漏洞是否更贴近业务逻辑如业务逻辑缺陷、权限问题而非简单的注入或XSS扫描深度检查扫描的请求数量、测试的参数数量。自定义策略应该对关键接口进行了更密集的测试。误报率手动验证新发现的漏洞计算误报比例。一个好的策略应在提高发现率的同时控制误报。报告整理AWVS生成的报告需要人工复核和润色。对于自定义规则发现的漏洞在报告备注中应详细说明触发漏洞的请求参数、攻击载荷和服务器响应特征方便开发人员快速复现和修复。可以将Burp Suite的请求/响应截图作为附件。最后自定义扫描策略不是一劳永逸的。随着电商网站功能的迭代更新旧的规则可能失效新的攻击面会出现。定期回顾和更新你的策略库将每一次手动测试中发现的新的测试模式沉淀为规则才能让这个“自动化放大镜”持续保持犀利。真正的安全测试是人的智慧与工具效率的完美结合AWVS的自定义规则正是连接这两者的桥梁。