七、CRLF 注入

作者:Peter Yaworski

译者:飞龙

协议:CC BY-NC-SA 4.0

CRLF 注入是一类漏洞,在用户设法向应用插入 CRLF 时出现。在多种互联网协议中,包括 HTML,CRLF 字符表示了行的末尾,通常表示为\r\n,编码后是%0D%0A。在和 HTTP 请求或响应头组合时,这可以用于表示一行的结束,并且可能导致不同的漏洞,包括 HTTP 请求走私和 HTTP 响应分割。

对 HTTP 请求走私而言,它通常在 HTTP 请求传给服务器,服务器处理它并传给另一个服务器时发生,例如代理或者防火墙。这一类型的漏洞可以导致:

  • 缓存污染,它是一种场景,攻击者可以修改缓冲中的条目,并托管恶意页面(即包含 JavaScript)而不是合理的页面。
  • 防火墙绕过,它是一种场景,请求被构造,用于避免安全检查,通常涉及 CRLF 和过大的请求正文。
  • 请求劫持:它是一种场景,攻击者恶意盗取 HTTPOnly 的 Cookie,以及 HTTP 验证信息。这类似于 XSS,但是不需要攻击者和客户端之间的交互。

现在,虽然这些漏洞是存在的,它们难以实现。我在这里引用了它们,所以你对如何实现请求走私有了更好的了解。

而对于 HTTP 响应分割来说,攻击者可以设置任意的响应头,控制响应正文,或者完全分割响应来提供两个响应而不是一个,它在示例 #2 (Shopify 响应分割)中演示(如果你需要 HTTP 请求和响应头的备忘录,请回到“背景”一章)。

1. Twitter HTTP 响应分割

难度:高

URL:https://twitter.com/i/safety/report_story

报告链接:https://hackerone.com/reports/52042

报告日期:2015.4.21

奖金:$3500

描述:

2015 年 4 月,有报告称,Twitter 存在一个漏洞,允许攻击者通过将信息添加到发往 Twitter 的请求,设置任意 Cookie。

本质上,在生成上面 URL 的请求之后(一个 Twitter 的遗留功能,允许人们报告广告),Twitter 会为参数reported_tweet_id返回 Cookie。但是,根据报告,Twitter 的验证存在缺陷,它用于确认推文是否是数字形式。

虽然 Twitter 验证了换行符0x0a不能被提交时,验证机制可以通过将字符编码为 UTF-8 来绕过。这么做之后,Twitter 会将字符转换会原始的 Unicode,从而避免了过滤。这是所提供的示例:

  1. %E5%98%8A => U+560A => 0A

这非常重要,因为换行符在服务器上被解释为这样的东西,创建新的一行,服务器读取并执行它,这里是用于添加新的 Cookie。

现在,当 CRLF 攻击允许 XSS 攻击的时候(请见 XSS 一章),它们还会更加危险。这种情况下,由于 Twitter 的过滤器被绕过了,包含 XSS 攻击的新的响应可能返回给用户,这里是 URL:

  1. https://twitter.com/login?redirect_after_login=https://twitter.com:21/%E5%98%8A
  2. %E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D
  3. %E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE

要注意%E5%E98%8A布满了这个 URL。如果我们使用了这些字符,并且实际添加了换行符,这个就是协议头的样子:

  1. https://twitter.com/login?redirect_after_login=https://twitter.com:21/
  2. content-type:text/html
  3. location:%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE

你可以看到,换行符允许了创建新的协议头,并和可执行的 JavaScript 一起返回:svg/onload=alert(innerHTML)。使用这个代码,恶意用户就能够盗取任何无防备的受害者的 Twitter 会话信息。

重要结论

好的攻击是观察与技巧的组合这里,报告者@filedescriptor了解之前的 Firefox 编码漏洞,它错误处理了编码。对这个知识的了解就可以用于测试 Twitter 上相似的编码来插入换行。

当你寻找漏洞时,始终记住要解放思想,并提交编码后的值来观察站点如何处理输入。

2. Shopify 响应分割

难度:中

URL:v.shopify.com/last_shop?x.myshopify.com

报告链接:https://hackerone.com/reports/106427

报告日期:2015.12.22

奖金:$500

描述:

Shopify 包含了一些隐藏功能,会在你的浏览器上设置 Cookie,它指向你所登录的最后一个商店。它通过终端/last_shop?SITENAME.shopify.com来实现。

在 2015 年 12 月,有人发现,Shopify 不验证在调用中传入的shop参数。所以,使用 Burp Suite,白帽子就能够使用%0d%0a来修改请求,并生成协议头返回给用户。这里是截图:

七、CRLF 注入 - 图1

这里是恶意代码:

  1. %0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20te\
  2. xt/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>deface</html>

这里,%20表示空格,%0d%0a是 CRLF。所以浏览器收到了两个协议头,并渲染了第二个,它能够导致很多漏洞,包括 XSS。

重要结论

一定要寻找这样的机会,其中站点接受你的输入,并且将其用于返回协议头的一部分。这里,Shopify 使用last_shop值创建了 Cookie,它实际上可悲用户克隆的 URL 参数污染。这是一个不错的信号,它可能存在 CRLF 注入漏洞。

总结

良好的攻击是观察和技巧的结合。了解如何使用编码字符串来发现漏洞是一个不错的技巧。%0D%0A可以用于测试服务器,以及判断他们是否存在 CRLF 漏洞。如果存在,进一步尝试使用 XSS 注入来组合盖漏洞(请见第七节)。

另一方面,如果服务器不响应%0D%0A,要考虑如何再次编码这些字符,并测试服务器,以便观察它是否解码双重编码的字符,就像@filedescriptor所做的那样。

一定要寻找这样的机会,其中站点使用提交的值来返回一些类型的协议头,例如创建 Cookie。