Web应用防火墙接入文档的规则配置需要结合实际Web开发架构。根据现有资料，Web应用通常采用客户端-服务器结构，前端运行在浏览器中，后端运行在服务器上。规则配置应覆盖这两端的交互点。
理解前后端分工对规则的影响
根据来源[2]，前端开发主要使用HTML、CSS和JavaScript，负责数据的显示与初步交互；后端开发则涉及多种编程语言如Java、PHP、Python等，负责业务逻辑和数据持久化。规则配置时需关注前端提交的数据（如表单中的GET/POST参数）和后端返回的响应（如JSON、HTML中可能包含的敏感信息）。例如，对输入验证规则应作用于前端提交点，检查参数值是否包含恶意字符；而对敏感信息泄露的规则应作用于后端输出点，拦截响应中出现的信用卡号、密钥等模式。前后端职责分配由项目设计决定，规则需随之调整：若前端承担了大量计算，则规则需更严格地过滤前端请求；若后端仅提供数据，则规则应侧重于保护API端点。
规则匹配的逻辑与优先级
规则配置需定义明确的匹配逻辑。来源[1]提到“通过每一次检索广泛撒网”，在WAF中，规则应全面覆盖不同类型的请求，包括常见的HTML请求、API调用、甚至预印本和学位论文等学术资源（如果业务涉及）。但实际接入中需根据业务场景调整，避免过度拦截。规则通常按顺序匹配，优先级从高到低排列。常见做法是先配置全局默认规则（如禁止常见扫描工具、过滤XSS和SQL注入的通用模式），再针对特定URI或参数自定义规则。例如，对于登录接口，可增加对密码长度、特殊字符的限制；对于文件上传接口，则需检查文件类型和大小。规则顺序至关重要——若将宽松的放行规则置于严格规则之前，可能绕过安全检测。
常见误区与失败条件
误区一：忽略前后端职责分配。若规则设置过于严格，可能误拦正常请求。来源[2]指出，前后端任务分配由项目设计决定，规则也需与设计对应。例如，若前端使用JavaScript对用户输入进行加密后再提交，WAF规则若基于未加密内容检测，将无法发现恶意数据。误区二：仅依赖单一来源。来源[1]强调数据来源的多样性，规则应参考多种威胁情报，如OWASP规则集、商业威胁源以及自身业务日志。失败条件包括：未考虑数据库读写操作（后端常见，见来源[2]），导致规则无法拦截SQL注入（例如使用存储过程时，参数化查询可能绕过简单模式匹配）；或未考虑前端JavaScript渲染，导致规则遗漏基于DOM的XSS攻击。此外，忽略HTTP方法（如PUT、DELETE）和Content-Type（如multipart/form-data）也常导致规则失效。
规则配置的排查步骤
排查时，先检查请求是否到达后端。使用浏览器的开发者工具或抓包工具（如Wireshark）查看前端发送的数据是否被规则修改。再检查WAF日志和后端服务器日志，确认规则是否触发。若规则应生效却未拦截，常见原因包括：规则顺序错误（更优先级规则放行）、正则表达式编写不当（未转义特殊字符、未考虑大小写）、忽略HTTP方法或Content-Type。建议按以下顺序排查：确认规则是否启用并应用于正确的站点/路径；检查规则条件是否与请求特征精确匹配；使用测试工具模拟攻击请求，观察WAF响应；最后查看规则命中计数。
典型场景：从IP黑名单到SQL注入防护
一个典型规则配置流程如下：首先，为管理后台添加IP白名单规则，只允许来自公司公网IP的访问。其次，配置全局规则集，启用OWASP TOP 10的SQL注入与XSS规则。然后，针对文件上传路径，自定义规则禁止上传可执行脚本文件。最后，添加日志审计规则，记录所有被拦截的请求用于分析。每一步都需要验证：使用curl模拟异常IP请求，确认返回403；使用Payload测试SQL注入，确认被拦截。
参考资料
延伸阅读