CRLF注入攻击原理与防御详解

你好，今天我们来详细讲解CRLF注入攻击。这是一种相对基础但危害不容忽视的Web安全漏洞，常常被用于发动更复杂的组合攻击。

一、什么是CRLF注入攻击？

首先，我们得搞清楚“CRLF”是什么。

1. CRLF的含义：CRLF是两个特殊ASCII控制字符的缩写。

   • CR（Carriage Return，回车符）：ASCII码是 \r（十进制13）。它的本意是让打印机或终端的光标移动到行首。
   • LF（Line Feed，换行符）：ASCII码是 \n（十进制10）。它的本意是让光标移动到下一行。
   • 在HTTP协议、邮件报文等标准互联网文本协议中，\r\n 被用来标识一行内容的结束和另一行内容的开始。所以，“CRLF”通常指代这个行终止序列。

2. 攻击原理：CRLF注入攻击，有时也叫“HTTP响应头拆分”（HTTP Response Splitting）的旁支，其核心原理是攻击者能够将CRLF字符注入到HTTP响应流中，从而篡改原始的HTTP响应结构。

   • 当应用程序在处理用户输入（如URL参数、表单字段、Cookie值）时，如果未能正确过滤或转义CRLF字符，并将这些输入直接、未经验证地插入到HTTP响应头中，攻击者就有可能注入 \r\n。
   • 注入的 \r\n 会被服务器和客户端的HTTP解析器解释为换行。这使得攻击者可以提前结束一个响应头行，并插入全新的HTTP头，甚至直接开始HTTP响应体。

二、攻击发生的场景与条件

这种攻击通常发生在以下场景：

1. 用户输入被直接用于构造HTTP响应头：

   • 重定向：最常见的场景。例如，应用程序有一个登录后重定向的功能，URL参数是 redirect_to。
     • 正常URL：https://victim.com/login?redirect_to=/dashboard
     • 服务器代码可能生成：Location: /dashboard（一个响应头）
   • 设置Cookie：用户输入被用于设置Cookie的名称或值。
   • 其他自定义头：如 X-Forwarded-Host, Content-Disposition（文件下载名）等。

2. 缺乏对CRLF字符的有效过滤：应用程序没有对用于构建响应头的用户输入进行严格的验证、过滤或编码。例如，不应该允许 \r 和 \n 这两个字符直接出现在最终的响应头字符串里。

三、攻击步骤与利用方式详解

让我们通过一个经典的例子，一步步拆解攻击过程。

假设场景：
一个网站有登录重定向功能，代码逻辑如下（伪代码）：

# 从URL参数读取重定向目标
redirect_target = request.getParameter(“redirect_to”)
# 直接将用户输入拼接到Location响应头
response.setHeader(“Location”, redirect_target)

攻击步骤：

1. 探测漏洞：攻击者尝试构造一个特殊的 redirect_to 参数值，例如：
   ?redirect_to=/dashboard%0d%0aTestHeader: Hacked

   • %0d 是回车符 \r 的URL编码。
   • %0a 是换行符 \n 的URL编码。
   • 攻击者提交这个URL后，会观察服务器响应。如果服务器返回的响应中包含了 TestHeader: Hacked 这个头，就证明CRLF注入成功了。

2. 实施攻击：确认漏洞存在后，攻击者可以进行更危险的利用。例如，注入一个完整的 Set-Cookie 头，用于 会话固定攻击：

   ?redirect_to=/dashboard%0d%0aSet-Cookie: sessionid=attacker_controlled_session%3b%20HttpOnly
   

   • 这会生成如下响应头：

     HTTP/1.1 302 Found
     Location: /dashboard
     Set-Cookie: sessionid=attacker_controlled_session; HttpOnly
     ...
     

   • 用户的浏览器会接收并存储这个由攻击者设定的会话ID。当用户访问 /dashboard 时，就带上了攻击者已知的会话，从而可能被劫持会话。

3. 更危险的利用：HTTP响应拆分与XSS：
   CRLF注入的终极形态是“HTTP响应拆分”。攻击者可以注入两个连续的CRLF（\r\n\r\n）来提前结束HTTP响应头部分，并开始伪造HTTP响应体。

   ?redirect_to=/dashboard%0d%0a%0d%0a<script>alert(‘XSS’)</script>
   

   • 生成的响应会变成：

     HTTP/1.1 302 Found
     Location: /dashboard
     
     <script>alert(‘XSS’)</script>
     

   • 由于 \r\n\r\n 标识了HTTP头的结束，浏览器会将 Location: /dashboard 之后的全部内容（包括我们注入的JavaScript）解析为响应体，并执行其中的脚本，从而造成反射型XSS攻击。这种方式甚至可以绕过一些基于“输出在HTML上下文”的XSS防护。

4. 利用请求走私：如果CRLF被注入到HTTP请求中（例如通过某种代理或中间件），也可能用于HTTP请求走私攻击（HRS），但这属于更复杂的变种。

四、攻击的危害

CRLF注入的危害是多样化的：

1. 会话劫持与固定：如前所述，可以注入恶意Cookie。
2. 跨站脚本（XSS）：通过响应拆分实现，危害巨大。
3. 网站内容篡改：可以注入任意HTTP头，如 X-Frame-Options 来禁用点击劫持防护，或注入虚假的缓存控制头。
4. 信息泄露：可能通过注入头来影响浏览器的安全策略。
5. 与其他漏洞组合利用：作为初始攻击向量，为更复杂的攻击铺路。

五、防御措施详解

防御的核心原则是：永远不要信任用户输入，尤其是在构造协议元素时。

1. 严格的输入验证与过滤：

   • 白名单校验：对于像重定向URL这样的输入，最好使用一个预定义的白名单进行匹配。例如，只允许重定向到 [“/dashboard”, “/profile", "/home”] 等有限的、安全的内部路径。
   • 黑名单移除：如果白名单不适用，必须对用于构建响应头的输入进行严格的过滤，移除所有可能的CRLF字符（\r, \n, 及其各种编码形式如 %0d, %0a, \u000d 等）。注意，要确保在解码（URL解码、Unicode解码）之后再进行过滤。

2. 安全的编码输出：

   • 当必须将用户输入放入HTTP响应头时，应对输入进行头部值编码。大多数现代Web框架的响应头设置API会自动处理这个问题。例如，如果你试图设置 Location: user_input，框架会自动对 user_input 中的换行符等进行编码或拒绝。
   • 切勿手动拼接字符串来构建响应头，始终使用框架提供的安全API。

3. 使用安全的重定向方式：

   • 避免使用用户提供的完整URL进行重定向。如果需要外部重定向，应使用一个映射ID（如 redirect_id=1），在服务器端映射到安全的硬编码URL。
   • 如果必须重定向到动态路径，应对路径进行规范化（移除../等）并确保其位于当前域名下。

4. 定期安全测试：

   • 在渗透测试或漏洞扫描中，将CRLF注入作为常规测试项。手动测试时可以尝试在参数值末尾添加 %0d%0a 序列，并观察响应头的变化。

总结：
CRLF注入攻击利用的是应用程序在处理用户输入与协议边界（换行符）时的疏忽。防御的关键在于对任何用于构建HTTP头部（或任何其他基于行的协议）的用户输入进行严格的验证、过滤和编码，并优先使用白名单机制。理解了这种攻击，你就能更好地理解Web应用中协议级的安全边界的重要性。