实战Web安全测试之HTTP截断(走私漏洞篇)

• 走私
• 漏洞
• 测试
• 安全
• 实战
• 攻击
• HTTP
• 消息
• 一个
• 应

在本文中，我们将详细为读者介绍针对HTTP截断和HTTP走私攻击的安全测试技术。我们将通过实例演示如何利用HTTP协议的某些特性，或者利用Web应用程序的弱点或者不同代理对HTTP消息的解释也不相同的特点来发动这两种攻击。

一、HTTP截断/走私漏洞概述

本文遏制，我们将分析针对特定的HTTP报头的两种不同的攻击技术：HTTP截断和HTTP走私攻击。对于HTTP截断攻击而言，它是利用了缺乏输入消毒措施的漏洞，该漏洞允许入侵者向应用程序响应的头部插入CR和LF字符，从而将响应分割为两个不同的HTTP消息。该攻击的目标既不同于缓存投毒，也区别于跨站脚本攻击。对于第二种攻击方法，攻击者利用了这样的一个事实，即一些专门精心制作的HTTP消息可能会随着接收它们的代理的不同，而作不同的解析和解释。HTTP走私技术要求对处理HTTP消息的各种代理相当熟悉，否则无法发动这种攻击。

下面我们介绍这些漏洞的黑盒测试和灰盒测试技术。

二、HTTP截断攻击黑盒测试

一些web应用程序会使用部分用户输入来生成它们的响应头部的某些值，这方面最简单的例子就是重定向了，因为目标URL依赖于用户提交的某些值。举例来说，假如用户被要求在标准web接口和高级web接口之间做出选择，然后，选择的结果将作为一个参数传递，并且这个参数将用于触发重定向到相应的页面的应答头中。更确切地说，如果该参数interface的值是advanced，那么应用程序将响应下列内容：

图1

收到这个消息后，浏览器会把用户引向Location头部规定的页面。然而，如果应用程序没有对用户输入进行过滤的话，攻击者就可以在参数interface中插入序列%0d%0a，而该序列代表的则是用于分割各行的CRLF(回车换行)序列。这样一来，攻击者将能够触发一个响应，重要的是任何解析器(例如介于用户和Web应用之间的web缓存)都会把这个响应会被解释为两个不同的响应。所以，攻击者就可以通过给这个web缓存“投毒”以使它为后续的请求中提供虚假的内容。例如，在我们前面的例子中，假设攻击者将下列内容作为参数interface进行传递：

图2

从存在漏洞的软件(也就是没有对用户输入进行严格消毒的应用程序)中得到的响应将是下面的内容：

图3

Web缓存将看到两个不同的响应，因此如果攻击者发送第一个请求之后立即发送对/index.html页面的请求的话，web缓存会认为这个请求与第二个响应相匹配，并缓存它的内容，这样一来后面经由web缓存的所有指向victim.com/index.html的请求都会收到系统故障消息，即“system down”。通过这种方式，一个攻击者将能有效涂改站点在使用web缓存的用户心中的形象，如果该web缓存是该Web应用程序的一个反向代理的话，那么这个Web应用程序在整个因特网中的用户都会受到影响。另外，攻击者还可以向这些用户传输发动跨站脚本攻击攻击的JavaScript代码片断，例如窃取cookies等。需要注意的是，虽然该安全漏洞位于应用程序中，但是攻击针对的对象却是使用该应用程序的用户。

因此，为了查找这个安全漏洞，渗透测试人员需要识别所有能够影响响应的一个或多个头部的用户输入，并检查用户是否能够在其中注入一个CR+LF序列。与这个攻击关系最密切的两个头部是：

Location Set-Cookie

需要注意的是，现实中要想成功利用这个安全漏洞可能是件非常复杂的事情，因为有多种因素必须考虑到：

1.攻击者要想让伪造的响应被缓存的话，必须正确设置其中的各个头部，例如Last-Modified头部的值必须设为将来的一个时间。此外，攻击者还必须破坏目标页面先前的缓存版本，方法是提交一个请求头部中带有“Pragma: no-cache”的前导请求来防止页面被缓存。

2. 即使应用程序没有过滤CR+LF序列，但是仍可能过滤了发动该攻击所需的其他字符，例如字符<和>等。这时候，攻击者可以尝试使用其他编码，例如UTF-7编码等。

3. 某些攻击目标(例如ASP)会对Location头部(例如www.victim.com/redirect.asp )中的路径部分进行URL编码处理，这样就使得CRLF序列不起作用了。然而，它们却不能对查询部分(例如?interface=advanced)进行这样的编码处理，这意味着放置一个前导问号就能够绕过这种过滤技术。#p#副标题#e#

三、HTTP截断攻击灰盒测试

对于Web应用程序即攻击目标的深入了解，在发动HTTP截断攻击时是极其有帮助的。例如，不同的攻击目标可能使用不同的方法来判定第一个HTTP消息在何时终止，第二个HTTP消息从什么时候开始。当然，有时候可以使用消息边界来进行判定，如上面的例子就是这样。但是，其他的攻击目标可能使用不同的数据包来携带不同的消息。此外，有些目标会为每个消息分配指定组块的数量，这种情况下，第二个消息必须从特定的块开始，这就要求攻击者在两个消息之间填充必要的块。不过，当时有URL发送有弱点的参数的时候，这么做可能会引起一些麻烦，因为过长的URL很可能被截断或者过滤掉。灰盒测试可以帮助攻击者找到解决办法：一些应用程序服务器允许使用POST而非GET来发送请求。

四、HTTP走私攻击灰盒测试

之前讲过，HTTP走私攻击所利用的漏洞是，某些精心构造的HTTP消息会随不同的代理(浏览器、web缓存、应用程序防火墙)而做不同的解释。 这种攻击方法是由Chaim Linhart、Amit Klein、Ronen Heled和Steve Orrin于2005年发现的。这种攻击有多种用途，我们这里仅介绍最雷人的一种：绕过应用程序防火墙。

下面，我们详细介绍利用HTTP走私攻击绕过应用程序防火墙的详细方法。有许多应用防火墙都能根据一些已知的嵌入请求的恶意模式来检测和阻止怀有恶意的web请求。举例来说，针对IIS服务器的Unicode目录遍历攻击能够通过提交一个类似下面所示的一个请求发动攻击：

图4

当然，通过检查URL是否存在类似“..”和“cmd.exe”的字符串可以很容易地检测和过滤掉这种攻击。然而，IIS 5.0对于POST请求主体的长度是有要求的，最多为48K字节——当Content-Type头部不同于application/x-www-form-urlencoded时，超出该限制的部分会被全部截断。攻击者可以利用这一点来创建一个很大的请求，如下所示：

图5

这里，Request #1由49223字节内容组成，所以Request #1还包含了Request #2的几行内容。因此，防火墙(或者其他任何代理)会看到Request #1，但是却无法看到Request #2(它的数据正好是#1请求的一部分)，能够看到Request #3却会遗漏Request #4(因为该POST正好是伪造的头部xxxx部分)。现在，IIS 5.0将会发生什么情况?它将在49152字节无用信息之后停止对Request #1的解析，因为这已经达到了48K=49152字节的限制，并将Request #2解析为一个新的、单独的请求。Request #2声称它的内容为33字节，包括xxxx :之前的所有内容，这使得IIS会漏掉Request #3，因为Request #3被解释为Request #2的一部分，但是IIS会认出Request #4，因为它的POST是从Request #2的第33个字节之后开始的。当然，这看起来有些复杂，但是却很好的解释了为什么该攻击性URL不会被防火墙发现，却能被IIS正确解析和执行的原因所在。

在上面的情形中，虽然我们利用的是web服务器中的安全漏洞，但是在其他情形中，我们可以通过利用各种支持HTTP的设备在解析不兼容1005 RFC的消息时所采取的方式各不相同来发动攻击。举例来说，HTTP协议只允许一个Content-Length头部，但是却没有规定如何处理具有两个Content-Length头部的消息。一些实现将使用第一个，而另一些实现则使用第二个，这种情况下就很容易遭到HTTP走私的攻击。另一个例子是GET消息中Content-Length头部的使用。

五、小结

在本文中，我们详细为读者介绍了针对HTTP截断和HTTP走私攻击的安全测试技术。我们通过实例演示了如何利用HTTP协议的某些特性，或者利用Web应用程序的弱点或者不同代理对HTTP消息的解释也不相同的特点来发动这两种攻击。希望本文对读者的安全测试工作有所帮助。

【51CTO.COM 独家特稿，转载请注明出处及作者!】