商品搜索、优惠码校验和订单查询都可能接收用户输入。攻击者若把恶意语句混入参数，试图读取或篡改数据库，单靠封闭端口并不能识别请求内容。理解应用层安全设备与网络防火墙区别，关键是把它们放在不同控制点：前者检查应用请求，后者限制网络连接范围，并通过日志协作缩短排查时间。
先分清两者各自能做什么
网络防火墙通常依据源、目的地址、端口、连接状态和协议控制流量。例如，可只让公网流量到达网站入口，再限制入口服务器访问数据库的网络路径。它能减少不必要的暴露面，但仅放行常用网站端口，并不代表这些端口上的请求都是安全的。
应用层安全设备更关注请求结构和语义，例如参数里是否出现与查询语句有关的异常组合、请求是否违反已设定的应用规则。它可以告警或拦截可疑请求，但规则可能误报，也无法代替网站自身的权限校验和代码修复。不同产品的检测能力有差异，不能只凭名称判断。
攻击发生时，按入口、请求和后端分层处理
1. 先收紧网络可达范围
核对公网入口、源站和数据库之间的访问关系。防火墙只保留业务必需的连接，避免数据库直接接受公网连接；同时检查管理通道是否与顾客访问流量隔离。不要因一条告警就封锁全部网站流量，应结合受影响的入口和业务功能调整规则。
2. 在应用入口检测并限制恶意请求
将应用层检测设备放在网站入口前或反向代理链路中，对商品搜索、订单查询等接收参数的接口设置检测策略。先以观察或告警方式确认正常请求特征，再逐步启用拦截；针对重复触发的来源，可结合账号、会话、接口和时间窗口限速，减少误伤正常顾客的可能。
HTTPS流量若在设备处保持加密，设备通常无法直接检查其中的请求内容。要进行内容检测，需由受控的入口环节解密后检查，或使用其他能提供相应可见性的架构；部署前应评估证书管理、隐私要求、性能和故障切换方式。
3. 把告警对应到源站和代码
为防火墙、应用层设备、反向代理和网站服务统一校准时间，并记录可关联的请求标识、目标接口、处置动作及源地址。收到告警后，按以下顺序处理：
- 确认告警对应的接口、参数位置、时间和拦截结果，判断是否有请求到达源站。
- 对照源站访问日志与设备记录，检查同一时间段是否出现相似请求、异常响应或数据库错误。
- 必要时临时收紧相关接口的访问策略，并保留日志；避免只封单个地址而忽视持续变化的请求来源。
- 修复应用代码：数据库访问优先采用参数化查询，校验输入格式，并按业务需要收紧数据库账号权限。
- 在测试环境验证正常搜索、下单和订单查询，再逐步恢复或调整拦截策略。
协同原则：设备拦截不等于漏洞已修复
网络防火墙控制“谁能连到哪里”，应用层安全设备判断“请求是否像攻击”，应用代码则决定输入会不会被错误地当作数据库指令执行。三者应形成纵深防护：网络策略缩小可达面，应用层规则提供及时发现与拦截，参数化查询等修复从根源降低注入风险。这也是理解应用层安全设备与网络防火墙区别后最重要的落地结论。
常见问题
网络防火墙已经启用，是否还要应用层检测？
如果业务对外接收动态参数，防火墙的端口放行规则通常不能判断参数语义。是否部署应用层设备，应根据风险、架构和运维能力评估。
应用层设备能彻底阻止注入吗？
不能保证。规则覆盖、加密流量可见性和应用变化都会影响检测；应同步修复代码并测试。
检测到攻击后，应该先封IP还是改代码？
先依据证据采取临时限流或拦截，降低即时风险；随后排查请求是否到达后端并修复漏洞。单独封禁来源不能替代代码修复。
怎样减少正常顾客被误拦？
先观察告警并分析正常请求，再分接口逐步启用拦截，保留回滚办法，重点复测搜索、购物车和订单查询等关键流程。
发生注入攻击时，防火墙收紧连接边界，应用层设备识别请求异常，开发与运维人员完成日志核查和代码修复。把应用层安全设备与网络防火墙区别落实到这条协作链上，才能避免把一次设备拦截误认为问题已经解决。
