ACME http-01身份验证实现中的XSS漏洞分析与利用

漏洞概述

本教学文档详细分析了一种基于ACME http-01身份验证实现方式的跨站脚本(XSS)漏洞。该漏洞影响多个托管服务提供商，使得大量实现了http-01 ACME-challenge的网站容易受到XSS攻击。

ACME http-01验证机制

ACME http-01验证是Let's Encrypt等证书颁发机构使用的一种域名验证方法，其标准工作流程如下：

证书申请者需要在/.well-known/acme-challenge/目录下放置一个特定文件
Let's Encrypt会向该URL发送请求
期望响应格式为KEY1.KEY2
验证通过后颁发证书

漏洞产生原因

某些托管服务提供商采用了非标准的实现方式：

从请求URL中提取KEY1(如/ABC123)
将其与固定的KEY2(如XYZ567)组合
返回响应ABC123.XYZ567

这种实现方式导致了XSS漏洞的产生，因为攻击者可以控制响应中的部分内容。

漏洞利用的挑战与绕过方法

虽然存在三种缓解措施，但均可被绕过：

1. 内容类型(Content-type)未设置为HTML

绕过方法：

Apache Magic MIME：根据响应首字节确定内容类型
- <b> → text/html
- <?xml → text/xml
Internet Explorer技巧：
- 创建.eml文件，设置Content-Type: message/rfc822
- IE会对其余内容执行MIME-sniffing
- 通过iframe加载易受攻击端点，内容被视为HTML

2. Web浏览器对请求进行URL编码

绕过方法(针对IE)：

IE中URL的查询部分(?后)默认不进行URL编码
构造如/.well-known/acme-challenge/?<h1>hi的请求
即使重定向，IE也会保留非URL编码部分

3. XSS审核程序的拦截

绕过方法：

控制内容类型为XML/XHTML
Chrome XSS-auditor不会触发XML内容
提供XHTML命名空间，使XML作为HTML评估

漏洞利用PoC

针对国际提供商的PoC

/.well-known/acme-challenge/%3C%3fxml%20version=%221.0%22%3f%3E%3Cx:script%20xmlns:x=%22http://www.w3.org/1999/xhtml%22%3Ealert%28document.domain%26%23x29%3B%3C/x:script%3E

针对瑞典供应商的PoC

TESTEMLContent-Type: text/htmlContent-Transfer-Encoding: quoted-printable
< iframe src = 3D"http://[redacted]/.well-known/acme-challenge/?<HTML >< h1 > meh </ h1 > "> </ iframe >

缓解措施

根本解决方案：不要将acme-challenge请求中的内容泄露到响应中
标准实现：严格遵循ACME协议，仅提供KEY1.KEY2格式的响应
内容类型控制：强制设置Content-Type: text/plain并禁用MIME-sniffing
输入过滤：对URL中的特殊字符进行严格过滤和编码

总结

该漏洞展示了看似无害的实现细节如何导致严重的安全问题。托管服务提供商应严格遵循标准协议实现，避免引入潜在的安全风险。开发人员也应了解不同浏览器的特殊行为，以便全面评估安全风险。

ACME http-01身份验证实现中的XSS漏洞分析与利用漏洞概述本教学文档详细分析了一种基于ACME http-01身份验证实现方式的跨站脚本(XSS)漏洞。该漏洞影响多个托管服务提供商，使得大量实现了http-01 ACME-challenge的网站容易受到XSS攻击。 ACME http-01验证机制 ACME http-01验证是Let's Encrypt等证书颁发机构使用的一种域名验证方法，其标准工作流程如下：证书申请者需要在 /.well-known/acme-challenge/ 目录下放置一个特定文件 Let's Encrypt会向该URL发送请求期望响应格式为 KEY1.KEY2 验证通过后颁发证书漏洞产生原因某些托管服务提供商采用了非标准的实现方式：从请求URL中提取 KEY1 (如 /ABC123 ) 将其与固定的 KEY2 (如 XYZ567 )组合返回响应 ABC123.XYZ567 这种实现方式导致了XSS漏洞的产生，因为攻击者可以控制响应中的部分内容。漏洞利用的挑战与绕过方法虽然存在三种缓解措施，但均可被绕过： 1. 内容类型(Content-type)未设置为HTML 绕过方法： Apache Magic MIME ：根据响应首字节确定内容类型 <b> → text/html <?xml → text/xml Internet Explorer技巧：创建 .eml 文件，设置 Content-Type: message/rfc822 IE会对其余内容执行MIME-sniffing 通过iframe加载易受攻击端点，内容被视为HTML 2. Web浏览器对请求进行URL编码绕过方法(针对IE)： IE中URL的查询部分( ? 后)默认不进行URL编码构造如 /.well-known/acme-challenge/?<h1>hi 的请求即使重定向，IE也会保留非URL编码部分 3. XSS审核程序的拦截绕过方法：控制内容类型为XML/XHTML Chrome XSS-auditor不会触发XML内容提供XHTML命名空间，使XML作为HTML评估漏洞利用PoC 针对国际提供商的PoC 针对瑞典供应商的PoC 缓解措施根本解决方案：不要将acme-challenge请求中的内容泄露到响应中标准实现：严格遵循ACME协议，仅提供 KEY1.KEY2 格式的响应内容类型控制：强制设置 Content-Type: text/plain 并禁用MIME-sniffing 输入过滤：对URL中的特殊字符进行严格过滤和编码总结该漏洞展示了看似无害的实现细节如何导致严重的安全问题。托管服务提供商应严格遵循标准协议实现，避免引入潜在的安全风险。开发人员也应了解不同浏览器的特殊行为，以便全面评估安全风险。