我刚被德勤（Deloitte）代表SFDC进行了安全审核。基本上，我们使用flex并通过AMF进行通信。为此，我们使用FluorineFX（与LCDS和Blaze相反）。有人告诉我们，因为AMF响应未编码，并且有人可以操纵AMF参数并插入Javascript，这是XSS漏洞。我正在努力了解如何通过浏览器或其他任何方式执行AMF响应，该响应可能在错误消息中回显JS中传递的响应。我对使用HTML和JS的XSS很有经验，但是看到它被AMF标记很令人惊讶。我与FluorineFx团队保持联系，他们也感到困惑。
看到AMF库对响应数据进行编码，我会感到惊讶，而Fluorine肯定不会。看起来像PortSwigger和IBM AppScan这样的安全应用程序在其工具箱中包括了这种类型的测试。您是否已使用AMF遇到此漏洞，并且可以解释XSS问题如何表现出来？只是好奇。如果存在论点，我需要争论自己的出路，或者修补漏洞。鉴于Flex使用AMF的情况，我想您可能会有所了解。
附加信息 ...
因此，实际的卖方PortSwigger对此提供了更多信息。我向他们和网提出问题，网，他们承认这种攻击极为复杂。最初，他们将其归类为“高严重性”安全问题，但我认为他们的情况正在发生变化。我认为我会为大家发布他们的回复内容，因为我认为这种观点仍然很有趣。
---来自PortSwigger的问题---
感谢您的留言。我认为答案是，这可能是
漏洞，但并非易事。
没错，当回应被某人占用时，不会出现此问题
AMF客户端（除非它做一些愚蠢的操作），但是如果攻击者可以
设计一种情况，其中浏览器占用了响应。最
浏览器将忽略HTTP Content-Type标头，并查看
实际的响应内容，如果看起来像HTML一样，将会很高兴
这样处理。从历史上看，许多袭击发生在人们
将HTML / JS内容嵌入其他响应格式（XML，图像，其他
应用程序内容），并由浏览器照此执行。
因此，问题不只是回应的格式，而是
产生请求所需的格式。对于一个人来说，这不是一件小事。
攻击者设计包含有效AMF消息的跨域请求。
包含类似XSS的XML请求/响应也出现了类似的情况
行为。当然可以创建一个有效的XML响应
浏览器将其视为HTML，但是挑战在于如何在
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攻击，可以轻松触发该攻击。
最佳答案
您似乎在这里回答了自己的问题。
因此，您有一个服务器端实现，该实现将参数传递给amf函数调用，并将输入数据包括在返回的输出中。
我理解这在很大程度上是理论上的攻击，因为它涉及使有效负载由浏览器呈现，而不是进入amf客户端。甚至需要启用浏览器/插件中的其他漏洞才能启用此方案。只要通过浏览器将输出作为html / js进行处理，也许通过gateway.php之类的CSRF帖子就可以很容易地滥用它。
但是，除非您需要呼叫者能够将尖括号传递到响应中，否则只需对它们进行html编码或剥离即可，这种攻击情况就会消失。
不过这很有趣。通常，只为预期的数据使用者执行输出编码，但是有趣的是，浏览器可能经常是一种特殊情况。这确实是一个极端情况，但是我全都是为了人们养成清理和编码不可信输入的习惯。
这在很多方面让我想起了跨协议注入可用于滥用协议的反射功能（例如smtp）来在浏览器中实现XSS的方式。见http://i8jesus.com/?p=75