网站漏洞防护之HTTP请求方法篡改与安全限制

HTTP请求方法篡改，本质上不是漏洞本身，而是攻击者用来绕过安全机制的一种手段。当一台Web服务器或应用防火墙对GET请求做了严格过滤，却对POST、PUT、DELETE甚至一些冷门方法如HEAD、OPTIONS、TRACE、CONNECT大开绿灯时，攻击者就会利用这种配置差异发起攻击。最常见的场景是：一个登录接口只对GET请求做了SQL注入防护，攻击者抓包后把GET改为POST，原封不动地提交恶意参数，直接穿透防护。这不是代码漏洞，是配置盲区。

HTTP协议定义了多种请求方法，每种方法在RFC规范里有明确的语义。GET用于获取资源，POST用于提交数据，PUT用于更新资源，DELETE用于删除，HEAD只请求响应头，OPTIONS查询服务器支持的方法，TRACE用于调试回显，CONNECT用于建立隧道。问题在于，很多开发者和安全人员只关注GET和POST，对其他方法缺乏安全控制。一台默认安装的Apache或Nginx服务器，如果配置文件中没有显式限制，TRACE方法默认是开启的。攻击者利用TRACE方法可以发起跨站追踪攻击，结合XSS窃取HttpOnly标记的Cookie。这不是理论威胁，在实际渗透测试中，TRACE方法开启的站点比例至今仍然高得惊人。

第一种是绕过输入过滤。很多WAF规则只绑定在GET参数上，攻击者把请求包里的GET改成POST，请求体里带着SQL注入payload，WAF直接放行。第二种是绕过认证机制。某些RESTful接口用GET请求不需要认证，PUT和DELETE却需要，但开发人员忘记给POST加认证中间件。攻击者把GET改成POST，就能未授权操作敏感资源。第三种是利用服务器解析差异。不同Web服务器对请求方法的处理逻辑不同，IIS曾经有一个经典问题：当请求方法为自定义的任意字符串时，服务器会降级为GET处理，但安全模块可能不触发。攻击者把GET改成JUNK，恶意参数照样执行，安全设备却视而不见。

TRACE方法是最大的安全隐患之一。它的设计初衷是让客户端查看请求在传输过程中被代理服务器修改了什么，服务器会把收到的原始请求原样返回。攻击者可以构造一个包含恶意脚本的TRACE请求，结合浏览器漏洞或XSS，读取到包含敏感Cookie的请求头。即使Cookie设置了HttpOnly，TRACE回显中依然会包含。OPTIONS方法虽然危害相对较小，但它会返回服务器支持的请求方法列表，相当于给攻击者提供了一份攻击面清单。攻击者看到Allow头里包含PUT、DELETE、TRACE，就知道这些方法可能没有被禁用，可以针对性尝试。

CONNECT方法用于建立HTTP隧道，通常用于HTTPS代理场景。如果服务器开启了CONNECT方法且没有严格限制目标地址，攻击者可以利用这台服务器作为跳板，对内网其他主机发起请求，甚至扫描内网端口。这种攻击被称为HTTP代理滥用，在云环境里尤其危险。一台公网Web服务器如果开放了CONNECT方法，攻击者可以构造类似这样的请求：

CONNECT 192.168.1.100:22 HTTP/1.1
Host: vulnerable-server.com

如果服务器不加限制地建立连接，攻击者就相当于拥有了一台内网代理机器，后续的内网横向移动会变得异常简单。很多企业对外网Web服务器的安全加固只停留在WAF和漏洞扫描层面，完全忽略了CONNECT方法带来的网络层风险。

HTTP协议允许使用扩展方法，也就是不在标准RFC列表里的自定义方法。不同服务器对这种请求的处理方式完全不同。Apache遇到不认识的方法时，默认当作GET处理并执行后续逻辑。Nginx则比较严格，会返回400 Bad Request。但很多反向代理和中间件会放行任意方法，透传给后端。攻击者利用这一点，可以构造类似FOOBAR这样的方法，带上完整的恶意参数，前端代理放行，后端Apache当作GET处理，安全检测却因为方法名不匹配而失效。这种攻击在多层架构里尤其有效，因为每一层对HTTP规范的实现都有细微差别。

最彻底的防护是在Web服务器配置层面做方法白名单。Apache使用LimitExcept指令，只允许GET、POST、HEAD，拒绝其他所有方法。配置示例如下：

<Directory /var/www/html>
    <LimitExcept GET POST HEAD>
        Require all denied
    </LimitExcept>
</Directory>

Nginx通过limit_except指令实现同样的效果：

location / {
    limit_except GET POST HEAD {
        deny all;
    }
}

这种白名单方式比黑名单可靠得多。黑名单需要穷举所有危险方法，而HTTP扩展方法可以任意命名，黑名单永远列不完。白名单只开放业务真正需要的几种方法，其余一律拒绝，从根本上消除了方法篡改的威胁。对于TRACE方法，Apache和Nginx都有专门指令可以单独禁用。Apache使用TraceEnable off，Nginx在标准模块中默认不处理TRACE，但如果有proxy_pass配置，需要注意代理层是否处理TRACE。

服务器配置只是第一道防线，应用代码里也需要做方法校验。每个API接口在处理业务逻辑之前，应该先检查请求方法是否在允许范围内。以PHP为例：

$allowed_methods = ['GET', 'POST'];
if (!in_array($_SERVER['REQUEST_METHOD'], $allowed_methods)) {
    http_response_code(405);
    header('Allow: GET, POST');
    exit('Method Not Allowed');
}

这段代码放在入口文件的最前面，任何不被允许的方法都会直接返回405状态码。405和403有本质区别，405明确告诉客户端方法不被允许，同时Allow头列出合法方法，符合HTTP规范，也不给攻击者多余信息。Java的Spring框架可以通过@RequestMapping注解的method属性限制，但要注意，如果某个接口只写了@GetMapping，框架层面确实只接受GET，但底层容器如Tomcat如果配置不当，可能在其他方法上暴露出不同的行为。框架安全不能替代容器安全，两者需要配合。

WAF在防护请求方法篡改时有一个常见误区：很多WAF默认只检测GET和POST参数，对其他方法完全透传。安全人员需要检查WAF策略，确保所有请求方法都经过检测引擎，或者至少在WAF层面也做方法白名单。API网关是另一个关键节点，现代微服务架构里网关负责路由和认证，网关应该只转发明确定义的方法到后端服务。Kong、APISIX这类网关都支持方法级别的路由控制，配置路由时显式声明methods参数，未声明的方法自动返回405。这种做法把安全控制前移到网关层，后端服务即使有疏漏也不会被直接攻击到。

请求方法篡改攻击在日志里会留下明显痕迹。正常用户访问网站，请求方法几乎都是GET和POST，偶尔有HEAD用于缓存探测，OPTIONS用于CORS预检。如果日志里突然出现TRACE、CONNECT、PUT、DELETE或者各种随机字符串方法，大概率是扫描器或者攻击者在探测。建立基于请求方法的异常检测规则，统计每分钟内非标准方法的出现频率，超过阈值就告警。ELK或者Splunk这类日志平台可以轻松实现。同时要注意，攻击者可能会用大量GET请求淹没日志，把恶意方法请求混在其中，所以告警规则不能只看绝对数量，还要看方法种类分布的变化。

手动检查每个站点的方法限制配置效率太低，需要自动化工具辅助。Nmap的http-methods脚本可以快速检测目标服务器支持哪些方法：

nmap --script http-methods -p 443 target.com

输出会列出所有可用的方法，并标注危险方法如TRACE。Nikto扫描器也会自动检查TRACE方法和OPTIONS返回的信息。把这些检测集成到CI/CD流水线里，每次上线前自动扫描，发现危险方法直接阻断发布。对于已经运行的站点，定期用脚本批量检测，输出报告跟踪修复进度。这种自动化检测成本极低，但能持续发现配置漂移带来的风险。

单点防护永远不够，请求方法限制需要多层叠加。第一层在网络边界，防火墙或负载均衡器上只开放业务需要的方法。第二层在Web服务器，通过配置文件做白名单。第三层在应用代码，每个入口做方法校验。第四层在日志监控，实时发现异常方法请求。四层防御中任何一层失效，其他层依然能起到保护作用。这种纵深防御思路虽然看起来冗余，但在真实攻击场景中，攻击者往往就是利用某一层的疏忽完成突破。一个配置了WAF但服务器TRACE没关的站点，和没防护没有本质区别。

某电商平台的订单查询接口，原本只接受GET请求，参数通过URL传递。安全团队对GET参数做了严格的XSS和SQL注入过滤。攻击者在渗透测试中发现，把请求方法改为POST，参数放在请求体里，后端居然同样处理，而且绕过了所有过滤规则。根本原因是后端框架使用了通用的参数获取函数，不区分参数来源，而安全过滤插件只绑定了GET参数解析器。修复方案是后端接口显式声明只接受GET方法，非GET直接返回405，同时在框架全局中间件里增加请求方法白名单。这个案例说明，方法篡改攻击的成功率之所以高，是因为它利用了开发人员对HTTP协议理解不全面的认知盲区。

HTTP/3和QUIC协议的普及会带来新的方法处理差异。QUIC基于UDP，请求方法的处理逻辑在应用层实现，不同实现之间的差异可能比HTTP/1.1时代更大。GraphQL的流行也让方法限制变得复杂，GraphQL通常只使用POST，但查询操作理论上也可以用GET，如果配置不当，可能暴露出预料之外的攻击面。安全人员需要持续跟踪协议演进和框架更新，把请求方法限制作为安全基线的一部分，而不是一次性配置完就遗忘。安全配置的持续有效性验证，比初始配置本身更重要。