apache-flex - AMF 和跨站脚本漏洞混淆

Question

我刚刚代表 SFDC 接受了德勤的安全审计。基本上我们使用 flex 并通过 AMF 进行通信。为此，我们使用 FluorineFX(而不是 LCDS 和 Blaze)。我们被告知，由于 AMF 响应未编码，并且有人可以操纵 AMF 参数并插入 Javascript，因此这是一个 XSS 漏洞。我正在努力理解 AMF 响应如何返回，它可以在错误消息中回显在 JS 中传递的内容，可以由浏览器或其他任何东西执行。我对 HTML 和 JS 的 XSS 非常有经验，但看到它被 AMF 标记有点令人惊讶。我与 FluorineFx 团队保持联系，他们也很困惑。

我会惊讶地看到 AMF 库对响应数据进行编码，而 Fluorine 肯定不会。看起来像 PortSwigger 和 IBM AppScan 这样的安全应用程序在他们的工具箱中包含了这种类型的测试。您是否遇到过 AMF 的这个漏洞，您能解释一下 XSS 问题是如何表现出来的吗？只是好奇。如果存在争论，我需要争论我的出路，或者修补漏洞。鉴于 AMF 与 Flex 的使用，我认为您可能有一些见解。

附加信息...

因此，来自实际供应商 PortSwigger 的更多信息。我向他们和net提出了问题，net，他们承认这种类型的攻击极其复杂。最初他们将此归类为高严重性安全问题，但我认为他们现在正在改变。我想我会为你们所有人发布他们回复的内容，因为我认为这个观点仍然很有趣。

--- 从 PortSwigger 关于这个问题---

感谢您的留言。我认为答案是这可能是一个
漏洞，但利用起来并非微不足道。

你是对的，当响应被一个
AMF 客户端(除非它做了一些愚蠢的事情)，但如果攻击者可以
设计一种响应被浏览器消耗的情况。最多
浏览器将忽略 HTTP Content-Type header ，并将查看
实际的响应内容，如果它看起来像 HTML 会很高兴
像这样处理它。从历史上看，许多攻击都存在于人们
将 HTML/JS 内容嵌入其他响应格式(XML、图像、其他
应用程序内容)，这由浏览器执行。

所以问题不在于响应的格式，而在于响应的格式
生成它所需的请求格式。这对一个人来说不是微不足道的
攻击者设计包含有效 AMF 消息的跨域请求。
包含类似 XSS 的 XML 请求/响应也会出现类似的情况
行为。创建一个有效的 XML 响应当然是可能的
浏览器将其视为 HTML，但挑战在于如何将原始 XML 发送到
HTTP 正文跨域。使用标准的 HTML 表单无法做到这一点，
所以攻击者需要找到另一种客户端技术或浏览器怪癖，以
这样做。从历史上看，像这样的事情在不同时期都有可能发生，
直到它们被浏览器/插件供应商修复。我什么都不知道
这将允许它此刻。

简而言之，这是一种理论上的攻击，具体取决于您的风险状况
您可以完全忽略或阻止使用服务器端输入验证，或者
通过在服务器上编码输出并在客户端再次解码。

我确实认为 Burp 应该将 AMF 请求格式标记为缓解
这个问题，并将影响降级为低 - 我会解决这个问题。

希望有帮助。

干杯
港口斯威格

--- 有关审计的更多信息 ---

portSwigger 所做的不一定会弄乱二进制负载，它们所做的是弄乱发布到处理程序以引导请求的实际 AMF 参数。例如，这里是审计的片段，它显示了对请求的 AMF 响应的一部分......

HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
P3P: CP="CAO PSA OUR"
Content-Type: application/x-amf
Vary: Accept-Encoding
Expires: Tue, 06 Apr 2010 18:02:10 GMT
Date: Tue, 06 Apr 2010 18:02:10 GMT
Connection: keep-alive
Content-Length: 2595

......../7/onStatus.......
.SIflex.messaging.messages.ErrorMessage.faultCode.faultString
.faultDetail.rootCause.extendedData.correlationId.clientId.destination
.messageId.timestamp.timeToLive    body.headers.#Server.Processing..kFailed 
to locate the requested type 
com.Analytics.ca.Services.XXX5c2ce<script>alert(1)</script>9ccff0bda62..
....I506E8A27-8CD0-598D-FF6E-D4490E3DA69F.Id95ab281-d83b-4beb-abff-c668b9fd42d5
..fluorine.I04165c8e-f878-447f-a19a-a08cbb7def2a.A.q..@............
.        DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes
...[SNIP]...

注意那里的“警报”脚本......他们所做的是将一些包含 JS 的脚本附加到传递的参数之一，其中包含要调用的方法，即“com.Analytics.ca.Services.XXX”。通过这样做，JS 返回了一条错误消息，但是要使该 JS 接近执行，必须发生很多事情。充其量似乎是一种间接威胁。

-- 安全审计员的最新观点 --

我已经与更大的团队讨论过，我们都认为这是一次有效的攻击。正如 PortSwigger 在他的第一段中提到的，虽然理论上由于您将 content-type 设置为 x-amf，并且希望它不会在浏览器中呈现，但大多数浏览器都会忽略此请求并无论如何都会呈现它。我认为供应商在很大程度上依赖于设置内容类型的事实；然而流行的浏览器如 IE 和某些版本的 Safari 会忽略这一点。

通过利用 CSRF 或任何其他形式的 XSS 攻击很容易触发攻击。

Answer 1

您似乎已经在这里回答了您自己的疑问。

因此，您有一个服务器端实现，它将参数传递给 amf 函数调用，并在返回的输出中的某处包含输入数据。

我理解这主要是一种理论上的攻击，因为它涉及让有效负载由浏览器呈现，而不是进入 amf 客户端。甚至可能需要浏览器/插件中的其他漏洞才能启用此场景。只要浏览器将输出处理为 html/js，也许通过 gateway.php 或类似之类的 CSRF 帖子会使这很容易被滥用。

但是，除非您需要调用者能够将尖括号传递到响应中，否则只需对它们进行 html 编码或剥离，这种攻击场景就会消失。

不过这很有趣。通常，人们只会为数据的预期使用者执行输出编码，但考虑到浏览器通常可能是一种特殊情况，这很有趣。这确实是一种极端情况，但我完全支持人们养成对不受信任的输入进行 sanitizer 和编码的习惯。

这在很多方面让我想起了跨协议(protocol)注入(inject)可以用来滥用 smtp 等协议(protocol)的反射能力在浏览器中实现 XSS 的方式。见 http://i8jesus.com/?p=75