IIS HTTP方法配置信息泄露漏洞修复咨询（不影响运行）

一、禁用指定方法能否解决漏洞？ #

是的，禁用OPTIONS、TRACE、HEAD这三个方法确实能解决这类信息泄露问题：

• TRACE方法易被利用进行跨站追踪（XST）攻击，泄露会话凭证；
• OPTIONS会暴露服务器支持的所有HTTP方法，给攻击者提供攻击线索；
• HEAD虽风险较低，但若业务无需求，禁用可进一步缩小攻击面。

你可以在测试服务器配置完成后，用以下命令验证：

curl -X OPTIONS http://your-test-server:8080
curl -X TRACE http://your-test-server:8080
curl -X HEAD http://your-test-server:8080

若返回405 Method Not Allowed，说明配置生效，漏洞可被修复。

二、不影响业务的替代修复方案 #

如果担心直接禁用方法影响现有应用（比如部分API依赖HEAD做轻量资源检查），可尝试以下方案：

• 按需允许核心方法：不单独禁用，而是明确设置“仅允许GET、POST”这两个业务必需的方法，拒绝所有未授权的HTTP方法。这种方式比单独禁用更严谨，能避免遗漏风险。
• URL重写规则拦截：借助IIS的URL Rewrite模块添加规则，直接拦截OPTIONS、TRACE、HEAD请求并返回405，无需修改站点核心谓词配置，对现有应用影响极小，适合快速临时修复。
  示例配置（添加到web.config的<system.webServer>节点下）：

  <rewrite>
    <rules>
      <rule name="Block Unwanted HTTP Methods" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{REQUEST_METHOD}" pattern="^(OPTIONS|TRACE|HEAD)$" />
        </conditions>
        <action type="CustomResponse" statusCode="405" statusReason="Method Not Allowed" statusDescription="The requested method is not permitted." />
      </rule>
    </rules>
  </rewrite>
  

• 原生请求过滤配置：使用IIS自带的“请求过滤”功能，在“HTTP谓词”选项中添加拒绝规则，直接禁止OPTIONS、TRACE、HEAD方法。这是IIS原生安全机制，稳定性高，适合长期修复。

三、HTTP谓词配置为空的实际含义 #

IIS中HTTP谓词配置为空并非默认禁用所有方法，而是默认允许所有HTTP方法（包括OPTIONS、TRACE、HEAD）。只有当你明确设置“仅允许指定谓词”并列出允许的方法，或添加“拒绝”规则时，才会限制未授权方法。因此，配置为空时漏洞仍然存在，必须手动配置限制规则。

四、测试服务器验证步骤 #

1. 先备份测试服务器的web.config或IIS站点配置，确保可快速回滚；
2. 选择上述任意一种方案完成配置；
3. 用curl、Postman等工具分别发送OPTIONS、TRACE、HEAD请求，确认返回405；
4. 全面测试业务核心功能（如GET、POST请求），确保正常运行；
5. 用漏洞扫描工具重新检测，确认漏洞已修复。

内容的提问来源于stack exchange，提问作者Stefany Ramos