WAF 原理入门

WAF 入门

WAF 功能

WAF 全称叫 Web Application Firewall，和传统防火墙的区别是，它是工作在应用层的防火墙，主要对 web 请求/响应进行防护。那么 WAF 有什么功能呢？

防火墙都是防御性的产品，有防就有攻，要了解 WAF 有什么功能，就要从攻击者的角度去思考。

攻击的目的要么是为了利益，要么是为了炫技。目前攻击者大多都是闷声发大财，很少会为了炫技而惹上麻烦。那么，攻击目标越大，越有价值。

一个攻击者的目标由大到小，往往是这样 ：

• 全网
• 网络上某一主机
• 某一主机的数据库
• 某一主机 WEB 系统的管理员
• 某一主机 WEB 系统其它用户

假设一个 WEB 网络大致如下，图中为目前能得到仅有信息，下文会一步步完善。

WEB 服务器与浏览器之间已经用传统防火墙防护起来，也就是说，对 http://www.a.com 进行端口扫描之类的攻击行为已经没用了。攻击者可以通过下面步骤来得到这个网络的信息：

1. 通过 OPTIONS,TRACE 方法来探测里面的拓扑。如果 webserver 支持并允许这两个方法，通过检查响应包的 Via 或 Max-forwards 字段，可以得到各个节点的域名。

   

2. 通过检查响应包的 Server 字段或 X-Powered-By 字段来确定各个节点的 http 服务器软件版本和脚本语言解释器版本。同时由第一步得到的域名，也可以到相应域名注册网站（如站长之家）上查找 IP。而且有时候，由于网络管理员的疏忽，通向其它节点的路径并没有禁止端口扫描，那样通过端口扫描，可以得到系统信息，如操作系统类型，版本，开启了什么服务。然后在 CVE 上查询相应版本漏洞和 exploit-db 上下载相应的 payload 来攻击，获取主机的控制权。

   

3. 如果第二步不奏效，也可以通过 HTTP 的 OPTIONS 方法来获取网站支持的方法，比如允许 DELETE 方法，或者 PUT 方法，那么攻击者可以上传一个脚本获取整个站点的源代码和数据库数据甚至获取整个站点所有主机的权限，或者把认证的脚本给删除。

   

4. 如果第三步也不奏效，攻击者可能就会扫描所有网页，看是否存在文件路径遍历，文件包含注入，API 注入，命令注入之类的漏洞，来获取整个站点的系统信息甚至获取 webshell。

5. 如果第四步也不奏效，继续扫描所有页面，看是否有 sql 注入的漏洞，看能否获取站点的数据库数据或是否可通过数据库执行系统命令，获取主机权限。

6. 如果第五步也不奏效，只能看有没有 XSS，url 注入等漏洞，能否骗到其它合法用户的权限。或者看能否上传恶意文件。

再思考多一点，如果攻击者并没有打算攻陷 http://a.com 或从它偷取数据，而是频繁向 http://a.com 发送消耗大量资源的请求，比如请求会使用大量数据库查询的接口，或上传大量文件，导致正常服务无法响应。这种方式叫做 CC 攻击

那么，WAF 必须具备防护 CC 攻击能力，也就是说，WAF 具备限制对某些 URI 请求次数的能力和限制文件上传功能的能力。

从性能角度来看，由于 HTTP 是应用层的协议，每次 WAF 都要解析它，会造成很大性能损耗。而对于某些经常发恶意请求的 IP 或进行 CC 攻击的 IP，如果能够在网络层就把它们拦截了，对 WAF 性能是有很大的提升。所以 WAF 还必须具备 IP 黑名单的能力。

有黑名单就有白名单，对于某些资源，如图像，影音，css，js 文件，WAF 对它们应用规则，只会浪费计算资源和降低服务的响应速度，所以，需要把一些资源 URL 放在白名单里。

关于 IP 黑名单，再从安全运维角度来看，如果是 IP 黑名单是通过手工输入，那么，当攻击者使用 IP 池攻击，可能会导致 IP 黑名单的防护攻击失效。那么，如果 WAF 是支持动态黑名单，就可以很好解决这个问题。如果是由 WAF 本身产生黑名单，会对 WAF 性能有很大影响，所以 WAF 需要能够对接实时计算平台，由实时计算平台产生黑名单回馈给 WAF。那么 WAF 就必须支持与实时计算平台对接的能力。

总体来说，WAF 功能有如下：

• 禁止 HTTP 协议的非安全方法
• 伪装 Web 服务的特征
• 防止 API 和命令注入
• 防止路径遍历和文件包含注入，对敏感的系统路径进行保护
• 防止 sql 注入
• 防止 XSS 攻击
• 防止网页挂马
• 防护 CC 攻击
• 文件上传的防护
• 动态 IP 黑名单
• 白名单
• 与实时计算平台对接

WAF 部署模式

WAF 也是防火墙，那么它应该是部署在哪里呢？在部署上，它和传统防火墙有什么区别呢？

传统防火墙处理的消息格式大多是格式化，基本上内容都是固定或者索引方式。而 WAF 处理的消息是文本，是非格式化消息，都是可变的。在处理这两种不同的消息格式，在性能上的消耗相差非常大。我之前测试过，不使用正则，处理 http 内容匹配比格式化要慢上 5-20 倍，如果用上正则还可能再慢上 20 倍。

因此，如果 WAF 像传统防火墙那样，放置在网络入口，那么，对于 DDOS 攻击来说，它是很容易沦陷的。

所以 WAF 一般是部署在防火墙（特别是高防 DDOS 设备）后面，基本架构如下图

由于性能差异这么大，所以 WAF 和防火墙之间还会部署负载均衡设备。

那么，WAF 和 web 服务之间部署还会有什么方式？WAF 毕竟也是防火墙，而且它又有 web 服务的处理能力。所以它有下面四种部署方式：

1. 作为 WEB 服务器的模块。

   好处是，由于和 WEB 服务器结合紧密，对恶意请求的拦截准确率是最高，而且完全可以用 ModSecurity 或 naxis。缺点是，过于分散，不好管理和部署。

   

2. 作为一台反向代理服务器。好处是，部署方便简单，集中管理。缺点是，对恶意请求的误判率会上升。

   

3. 作为一台路由器。好处是，部署方便简单，集中管理。缺点是，也有单点问题，需要双机，同时由于作为一个路由器，需要在用户态上实现协议栈（TCP/IP），维护路由信息，不占用域名，对性能要求更高；且对 https 支持难度高。因此整体实现难度很高。

   

4. 作为一台交换机。好处是，部署方便简单，集中管理，不占域名，也不占用 IP，也就是说，对攻击者来说，它完全是透明的。缺点是，也有单点问题，需要双机，作为一个交换机，也需要在用户态实现协议栈（链路，TCP/IP），维护转发表，也由于同时防护多个站点，对性能要求高；且对 https 支持难度高。

   

在实际应用中，第一种模式基本只是学习者使用，一般用开源的 ModSecurity 或 Naxis 较多。第三，第四种模式过于复杂，而且出问题会导致整个子网出问题，也基本没见到使用。第二种模式，基本主流的 WAF 产品都是采用这种模式。

WAF 工作模式

由于 WAF 一般和业务系统是串联的，并且还是部署在业务系统前面。如果采用反向代理部署模式，假设 WAF 出现故障，那么会导致单个或者多个站点不可用。这意味着 WAF 的功能必须是随时可以关闭的。一个 WAF 往往需要同时防护多个站点，如果把整个 WAF 关闭，是会导致整体业务群都失去保护。所以，WAF 的工作模式必须有对站点随时关闭的模式。

当 WAF 有新功能或者有新策略发布，是不可以立马把新功能或新策略对现有站点进行防护，需要一段时间来进行观察，看功能是否可用或策略的命中率，漏判率和误判率。如果贸然上线的话，很容易背锅走人的。所以，WAF 的工作模式必须有监听模式。

不用说，WAF 工作模式当然要有防护模式。这是 WAF 存在的意义。

那么，这些工作模式如何设计呢？

先从关闭模式看起，对某个站点使用关闭模式，到这个站点的流量就感受不到 WAF 的存在。一般的做法，是解绑域名，再到 web 服务上绑定该域名。

这种做法优缺点如下：

优点

• 由于 web 服务和 WAF 完全分享，WAF 的故障不会影响到 web 服务。
• 少了 WAF 这个中间节点，web 服务的响应速度不受影响。

缺点

• 解绑和重绑，涉及到接入备案过程，流程较长，生效时间较长。
• 原先隐藏在内网的 web 服务集群对公网开放，除了 web 应用本身的攻击面，还增加了主机层面的攻击面，增大了整体网络的攻击面。

关闭模式也有一种快速生效的实现方式。这种实现方式和监听，防护两种模式的实现很统一。

这种方式的优缺点如下：

优点

• 不需要进行域名解绑和重绑，生效时间快
• 不会增加整体网络的攻击面

缺点

• 流量还是要经过 WAF，对 web 服务响应速度还是影响
• 流量要经过 WAF，所以 WAF 的故障也会影响到 web 服务

由于一个 IP 可以对应多个域名，一个域名也可以对应多个 IP，对针对每个域名来配置工作模式，WAF 必须要获取到 http 请求的 URL 或头部的 host 字段。WAF 解析完 http/https，拿到了请求的域名，再根据域名的配置，决定是否送去过规则还是直接传递给 web 服务。所以，WAF 的 http/https 模块解析要和规则引擎模块分开。

所以，WAF 的关闭模式如下图：

同样，WAF 的监听模式是既过规则，也会直接传递给 web 服务，大致如下图：

最后，WAF 的防护模式是直接过规则，不会直接传递给 web 服务，大致如下图：

可见，这样的设计，会使得这三种工作模式在实现和原理上都非常统一。

规则引擎原理

WAF 无非就是拦截有害请求和伪装响应，出于性能考虑，拦截有害请求又分为两个层面，由网络层拦截和由应用层拦截，且任何请求应该先在网络层过滤再到应用层过滤。也就是说，规则引擎分为两块，对请求过滤和对响应过滤，而对请求过滤分为两大步，网络层过滤和应用层过滤。

原理图大致如下：

请求部分

网络层

• 白名单：很多时候部署在 WAF 后面的应用，需要测试接口对非法输入的处理，但又不想关闭对该站点的监控，为了防止 WAF 对测试活动的影响，对来源 IP 和目标 IP 设置白名单，绕过 WAF 的拦截。从性能角度来考虑，白名单过滤功能是不可能放在其它过滤功能后面，那么它应该是规则引擎在网络层过滤的第一步。
• 黑名单：同样，对于已知有害的来源 IP，是越早拦截越好，出于性能考虑，黑名单拦截功能应该在网络层，那么它应该紧跟在白名单后面。

应用层

• https 拆解：随着 https 越来越普及，WAF 需要对 https 请求和响应进行检测和过滤，所以，WAF 必须支持使用证书对 https 内容进行拆解。
• http 方法防护：不少 http 方法是有安全风险的，如果 webserver 的配置有问题，如果不在这一步拦截掉，而 url 白名单的来源 IP 又可能被攻击，那么就可以存在站点沦陷的风险。一般是拦截除了 HEAD，GET，POST 之外的方法
• url 白名单：由于某些接口（如请求某些静态资源）并不会存在漏洞，没必要对这些 url 进行规则过滤，或者防护站点某些 url 接口有所更新，需要特定的来源 IP 进行测试。应当存在 url 和来源 IP 对应的白名单
• url 黑名单：同样由于某些接口的实现可能会涉及大量运算，可能需要对该 url 访问进行次数限制，需要存在一个 url 和次数的黑名单。
• http 请求解码：http 请求很多时候对头部和内容的数据往往会进行编码，如 url 编码，html 编码，js 编码，十六制编码，base64 编码，主要是为了传输一些二进制数据，或攻击者用于绕过各种防护设备。只有对数据进行解码，才能够知道它真实的 payload。所以需要对 http 请求进行解码。
• http 请求头部过规则：GET，HEAD 方法的参数都是紧跟 URL，这个阶段就可以进行过滤，而且先对请求头部过滤，也是基于性能考虑。毕竟请求 url 参数和头部都是 key-value 方式，解析相对比内容要快。
• http 请求内容过规则：POST 方法的参数基本都是放在请求内容里。

响应部分

• 响应头部过规则：响应头部有不少字段会泄露背后服务的关键信息，如 server 会泄露 webserver 软件及版本，x-powered-by 会泄露 cgi 语言和版本（PHP，Python,Perl,Ruby 之类），Via 和 Max-Forward 会泄露 WebServer 的拓扑。为了避免攻击者利用这些信息攻击，需要对响应头部某些字段进行屏蔽或伪装。
• 响应内容过规则：这一部分也叫做软补丁功能。为什么呢？如果 webserver 的应用服务抛异常了，并把异常信息显示在页面，这是一种常见的信息泄露。如果需要研发团队来修改和测试，运维团队对该服务进行打补丁上线，整个过程可能持续几周，存在很大的风险窗口。如果在 WAF 上，对这些信息进行伪装或屏蔽，就可以极大降低安全风险。更加不用那些会泄露用户信息，金融信息等服务。

WAF 动作

WAF 每条规则都会配置动作，对命中规则的请求进行对应的处理。

每个 WAF 产品对动作定义不大一样。

• ModSecurity 定义了 allow, block, deny, drop, pass, pause, proxy, redirect

  • allow: 命中了某条规则后，不需要对请求/响应应用其它规则，直接让请求通过。这个可以用于白名单。
  • block: 并不是一个真正的动作，它的行为取决于配置的默认动作，如果默认动作更新，使用 block 的规则行为也随即改变。在安全响应方面，它可用于批量进行规则作为更新。
  • deny: 中断规则处理，拦截请求/响应。在客户端的角度来说，这个动作会返回 4xx 或 5xx 的状态码（取决于规则定义 status)，但并没有中断当前的连接
  • drop: 对当前 tcp 连接进行关闭操作，它和 deny 的不同是：deny 之后，客户端仍然可以提交请求，但使用 drop 后，客户端只有重新连接才可以访问。这个动作可以节省后端服务的连接数
  • pass: 命中某条规则继续匹配下一条规则。可用于对请求进行精细地过滤，但会对响应速度有较大影响。
  • pause: 命中某条规则，对当前事务暂停指定的毫秒。一般用于防止登录爆破。如果遭受 DDOS 攻击，会恶化整个 web 服务的响应速度
  • proxy: 把命中规则的请求转发到另外一个 web 服务去。这个功能类似反向代理。由于它对客户端完全来说，完全是无感知，可以用它导向请求到蜜罐系统。这个动作是一个非常优秀的动作。
  • redirect: 当规则被命中，它会返回一个重定向，指示浏览器访问另外一个 url。它和 proxy 的区别是，它对客户端是感知。可用于配置新上线接口或屏蔽某些有问题的接口。

• Naxsi 定义了 accept, block, drop

  • accept: 对应 ModSecurity 的 allow，一旦命中立马放行
  • block: 对应 ModSecurity 的 deny
  • drop: 对应 ModSecurity 的 drop

• 华为云 WAF 定义了 allow, deny, redirect

  • accept: 对应 ModSecurity 的 allow，一旦命中立马放行
  • deny: 对应 ModSecurity 的 deny, 默认返回 418
  • redirect: 对应 Modsecurity 的 redirect

• openrestyl lua WAF 定义了 allow, deny，drop， redirect

  • accept: 对应 ModSecurity 的 allow，一旦命中立马放行
  • deny: 对应 ModSecurity 的 deny，默认返回 403
  • drop: 对应 ModSecurity 的 drop
  • redirect: 对应 Modsecurity 的 redirect

其中华为云 WAF 和 openresty lua WAF，在实现 pass 动作，都是通过规则组来实现。

对于动作配置方面，有这样的建议：

• 在功能开发方面，drop 最好能够先返回一个状态码再停止掉整个连接，drop, deny 状态码尽量可以通过规则配置。
• 在配置规则时，对于 drop, deny 的状态码，每条规则或规则组都返回不同的状态码。

这样做的好处是：

• 有效隐藏 WAF 的特征，让攻击者无法确认是否有 WAF 存在
• 当出现规则误拦截时，可以根据返回码快速定位是哪条规则误拦截。这是从无数次背锅感悟出来的血的教训

WAF 规则与报表

规则配置

首先，WAF 规则的定义是什么？

从前面的内容可以看到，基本上，WAF 处理 http 分为四个阶段：请求头部，请求内容，响应头部，响应内容。那么 WAF 规则就是，定义在某个阶段 WAF 对符合某种条件的 http 请求执行指定动作的条例。

根据这个，WAF 规则必须要包含这些元素：过滤条件，阶段，动作。由于 http 消息在传输过程中会对数据进行某种编码，所以，WAF 规则往往也需要定义解码器。同时为了审计作用，WAF 规则往往定义 id，是否对结果记录，以及字段抽取，命中规则的严重级别所以，一条 WAF 规则往往包含：id, 解码器，过滤条件，阶段，动作和日志格式，严重级别。

以一条 ModSecurity 规则为例：

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bsys\.user_catalog\b" \ "phase:2,rev:'2.1.3',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E, \ block,msg:'Blind SQL Injection Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1', \ tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score}, \ setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

看起来非常恐怖。翻译成 XML 就清晰多了

<rule>
    <id>959517</id>
    <version>2.1.3</version>
    <description></description>
    <severity>2</severity>
    <phase>2</phase>
    <decoder>none, urlDecodeUni,htmlEntityDecode,lowercase,replaceComments,compressWhiteSpace</decoder>
    <condition>
        <field>REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*</field>
        <operator>regex</operator>
        <pattern>\bsys\.user_catalog\b</pattern>
    </condition>
    <action>block</action>
    <tags></tags>
    <log>
        <format></format>
        <varibles></varibles>
    </log>
</rule>

规则陷阱

规则之间的关系非常复杂，特别过滤条件是使用正则表达式的，往往是会有包含关系，如[0-9]+包含了[1-2]+。那么，假设规则 a 先加入 WAF，后面又新增了条规则 b，在语法上，b 的过滤条件包含了 a，而且在配置上，不小心放在 a 前面，那么，就会出现误判的情况。

误判和漏判，是很常见的问题。但在严重程度上，却是不一样。

漏判，可能会造成恶意请求绕过 WAF，跑到业务后台，但在业务后台加上其它安全措施，却可以缓解威胁。误判，则是直接在 WAF 把正常请求给拦截掉，影响正常的业务。曾经某大厂重要业务部门上 WAF，由于误判，导致正常交易只有 50%成功，几上几下之后，WAF 团队的人基本干掉了。

所以，在测试环境，WAF 规则要越严格越好。但在生产环境，对有把握的规则才维持原样，其它规则尽量放宽松一些。

虽然 WAF 规则可以设置一个 id 用于追溯，这远远不够，因为无法追溯是由哪个消息触发，规则对消息处理的顺序是怎样。所以，一个稳妥的规则引擎，应当在 http 消息接收时，在头部增加一个消息 id，当消息离开 WAF 前，删除掉这个消息 id。通过这种方式，可以很好追溯到每条消息会触发哪些规则，触发结果是怎样。当出现误判情况下，也可以立马知道是哪些规则有问题，顺序是怎样，规则定义是否合理。

报表

WAF 报表除了是展示给用户看，还可以用于优化规则。如下面场景：

• 某些规则一直没有命中，配置起来只会浪费计算资源，影响用户体现。
• 某些规则虽然有命中，但命中率较低，应该是放置在后面，而命中率高的则应该调整在前面。
• 某些 URL 访问频率较高，且并非标准浏览器访问，需要进一步观察和分析，看是否会有漏判风险

那么，报表应该从哪些维度来展示呢？

先从语义来描述一下 http 消息流经 waf 的过程：

• 客户端 A 在物理地点 B，使用 IP 地址 C 访问站点 D，向 URL 地址 E 发起方法为 F 的 HTTP 请求 G，命中了解码器为 H，类型为 I，风险级别为 J，执行动作为 K 的规则 L
• 站点 M 向 IP 地址 N 返回响应 O，命中了解码器为 P，类型为 Q，风险级别为 R，执行动作为 S 的规则 T。

由语义来看，去重之后，报表的维度至少要包含：

• 客户端（user_agent)分布
• IP 地址，甚至是 IP 段分布
• 物理地点分布
• 站点分布分布
• URL 分布
• HTTP 方法分布
• 请求分布（这个会比较困难，基于长度来看会比较好）
• 解码器分布
• 规则类型分布（一般是指针对的攻击类型）
• 风险级别分布
• 动作分布
• 规则 ID 分布
• 响应分布（和请求分布一样困难）
• 时间分布（任何事件只能在时间中进行）
• 总请求数
• 拦截数量

每个维度并不是孤立，还会相互影响，纯组合可以达到 2^16=65536 种组合。

WAF 特征

在渗透或安全测试过程中，总是会发现不少 WAF 的存在。有些是有意展示自己的存在，作为一种广告，如华为云 WAF，CloudFlare 之类，有些是开发者的意识懒惰或没时间。

检测 WAF 存在，一般是几种方法：

• 查看响应头部字段，是否有特征字段或不寻常字段或某些常见字段缺失
• 查看响应内容
• 尝试各种 web 攻击类型，和正常请求对比返回的状态码或返回内容。
• 尝试 DOS 攻击，超过一定次数后，看该 IP 的连接是否 drop 掉，再用另外一个 IP 查看，如果正常，说明触发了黑名单或 CC 防护。可以确认 WAF 存在

下面是业务常见的 WAF 特征：

1. 360 Firewall：

   • 拦截状态码是 493
   • 响应头部包含 X-Powered-By-360WZB
   • 拦截的返回内容
   • 引用指向 http://wangshan.360.cn
   • 包含文本"Sorry! Your access has been intercepted because your links may threaten website security."

2. 阿里云盾：

   • 拦截的状态码为 405
   • 拦截的返回内容
   • 引用指向 http://errors.aliyun.com
   • 包含文本"Sorry, your request has been blocked as it may cause potential threats to the server's security"

3. AWS (Amazon)：

   • 拦截状态码为 403
   • 响应内容头部 server 包含"AWS"

4. 百度云加速

   • server 字段可能会为"Yunjiasu-nginx"或"Yunjiasu"

5. BitNinja:

   • 拦截响应内容会包含"Security check by BitNinja"

6. 思科 ACE XML Gateway：

   • server 字段有"ACE XML Gateway"

7. Cloudflare:

   • 响应头部：可能有 cf-ray 字段；server 字段包含"cloudflare";Set-Cookie 包含"__cfuid=".
   • 响应内容：可能包含"Attention Required!"或"Cloudflare Ray ID:"；请求无效 URL 会有"CLOUDFLARE_ERROR_500S_BOX"返回

8. 飞塔 FortiWeb：

   • 响应头部：在恶意请求返回情况会有"FORTIWAFSID="
   • 拦截返回的响应内容：会引用".fgd_icon"图标；页面内容会有"Server Unavailable!"

9. 华为云 WAF：

   • 拦截状态码为 418
   • 响应头部 server 为 HuaweiCloudWAF
   • 第一次响应"Set-Cookie"包含"HWWAFSESID"和"HWWAFSESTIME"

10. IBM DataPower：

    • 响应头部可能存在字段"X-Backside-Transport"，取值是"OK"或"FAIL"。

11. ModSecurity (Trustwave)：

    • 响应头部 server 可能会包含"Mod_Security"或"NYOB"
    • 拦截的响应内容会包含"This error was generated by Mod_Security", "One or more things in your request were suspicious", "rules of the mod_security module", "Protected by Mod Security"

12. NAXSI (NBS Systems)：

    • 响应头部：server 包含"naxsi/waf"；可能存在"X-Data-Origin"字段，值包含"naxsi/waf"
    • 响应内容：包含"This Request Has Been Blocked By NAXSI"

13. 绿盟 WAF

    • server 字段包含"NSFocus"

14. OpenResty Lua WAF：

    • 拦截状态码为 406
    • 响应头部：server 包含"openresty/{version}"
    • 拦截内容包含"openresty/{version}"

15. 腾讯云 WAF：

    • 拦截状态码为 405
    • 拦截内容会指向 http://waf.tencent-cloud.com

参考文章

转载自

• CSDN debugeeker
• https://zhuanlan.zhihu.com/p/542011331

如有侵权请联系博主删除