AMF与跨站脚本漏洞混淆
我刚刚受到德勤代表 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 提供了更多相关信息。我向他们和网络提出了问题，网络，他们承认这种类型的攻击非常复杂。最初他们将此归类为高严重性安全问题，但我认为他们的态度现在正在改变。我想我应该为大家发布他们的回复内容，因为我认为这个观点仍然很有趣。
--- 来自 PortSwigger 关于这个问题 ---
感谢您的留言。我认为答案是这可能是 漏洞，但利用起来并非易事。
你是对的，当响应被一个 AMF 客户端（除非它做了一些愚蠢的事情），而是如果攻击者可以 设计一种浏览器使用响应的情况。最多 浏览器将忽略 HTTP Content-Type 标头，并查看 实际的响应内容，如果它看起来完全像 HTML，我们会很高兴 像这样处理它。历史上，发生过多次袭击事件 将 HTML/JS 内容嵌入其他响应格式（XML、图像、其他 应用程序内容），这由浏览器执行。
因此，问题不在于响应的格式，而在于响应的格式。 生成请求所需的格式。对于一个 攻击者设计包含有效 AMF 消息的跨域请求。 包含类似 XSS 的 XML 请求/响应也会出现类似的情况 行为。当然可以创建一个有效的 XML 响应，该响应得到 浏览器将其视为 HTML，但挑战是如何发送原始 XML HTTP body跨域。使用标准 HTML 表单无法完成此操作， 因此攻击者需要找到另一种客户端技术或浏览器怪癖来 做这个。从历史上看，类似的事情在不同时期都有可能发生， 直到它们被浏览器/插件供应商修复。我什么都不知道 目前这样就可以了。
简而言之，这是一种理论上的攻击，具体取决于您的风险状况 您可以完全忽略或使用服务器端输入验证进行阻止，或者 通过在服务器上对输出进行编码并在客户端上再次解码。
我确实认为 Burp 应该将 AMF 请求格式标记为缓解措施 这个问题，并将影响降级为低 - 我会解决这个问题。
希望有帮助。
干杯 PortSwigger
--- 有关审计的更多信息 ---
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 在他的第一段中提到的那样，虽然从理论上讲，由于您将内容类型设置为 x-amf，并且希望它不会在浏览器中呈现，所以大多数浏览器都会忽略此请求并无论如何呈现它。我认为供应商严重依赖内容类型已设置的事实；然而流行的浏览器如 IE 和某些版本的 Safari 会忽略这一点。
通过利用 CSRF 或任何其他形式的 XSS 攻击，可以轻松触发该攻击。
I just got hammered on a Security Audit by Deloitte on behalf of SFDC. Basically we use flex and communicate via AMF. We use FluorineFX for this (as opposed to LCDS and Blaze). We are being told that because the AMF response is not encoded and that someone can manipulate the AMF parameters and insert Javascript that this is a XSS vulnerability. I'm struggling to understand how the AMF response back, which could echo the passed in JS in an error message, can be executed by the browser or anything else for that matter. I'm quite experienced with XSS with HTML and JS but seeing it get tagged with AMF was a bit of a surprise. I'm in touch with FluorineFx team and they are perplexed as well.
I'd be surprised to see an AMF library encode the response data, Fluorine surely does not. It would seem though that security applications like PortSwigger and IBM AppScan are including this type of test in their tool chest. Have you run into this vulnerability with AMF and can you explain how the XSS issue can manifest itself? Just curious. I need to either argue my way out of this if an argument exists or patch the hole. Given the AMF usage with Flex I thought you might have some insight.
Additional information ...
So A little more on this from the actual vendor, PortSwigger. I posed the question to them and net, net, they concede this type of attack is extremely complicated. Initially they are classifying this as a High Severity security issue but I think their tune is changing now. I thought I'd post the content of their response for you all as I think the perspective is interesting none-the-less.
--- From PortSwigger on the issue ---
Thanks for your message. I think the answer is that this is potentially a
vulnerability, but is not trivial to exploit.
You're right, the issue wouldn't arise when the response is consumed by an
AMF client (unless it does something dumb), but rather if an attacker could
engineer a situation where the response is consumed by a browser. Most
browsers will overlook the HTTP Content-Type header, and will look at the
actual response content, and if it looks at all like HTML will happily
process it as such. Historically, numerous attacks have existed where people
embed HTML/JS content within other response formats (XML, images, other
application content) and this is executed as such by the browser.
So the issue is not so much the format of the response, but rather the
format of the request required to produce it. It's not trivial for an
attacker to engineer a cross-domain request containing a valid AMF message.
A similar thing arises with XML requests/responses which contain XSS-like
behaviour. It's certainly possible to create a valid XML response which gets
treated by the browser as HTML, but the challenge is how to send raw XML in
the HTTP body cross-domain. This can't be done using a standard HTML form,
so an attacker needs to find another client technology, or browser quirk, to
do this. Historically, things like this have been possible at various times,
until they were fixed by browser/plugin vendors. I'm not aware of anything
that would allow it at the moment.
So in short, it's a theoretical attack, which depending on your risk profile
you could ignore altogether or block using server-side input validation, or
by encoding the output on the server and decoding again on the client.
I do think that Burp should flag up the AMF request format as mitigation for
this issue, and downgrade the impact to low - I'll get this fixed.
Hope that helps.
Cheers
PortSwigger
--- more info on audit ---
what portSwigger does is not necessarily mess with binary payload, what they do is mess with the actual AMF parameters that are posted to the handler to direct the request. For example here is a snippet from the audit and it shows part of the AMF response to a request ...
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]...
note the "alert" script in there ... what they did was appended some script enclosed JS to one of the parameters that are passed containing the method to call namely 'com.Analytics.ca.Services.XXX'. By doing so the JS came back in an error message but there are a lot of things that would have to happen for that JS to get anywhere close to executing. Seems an indirect threat at best.
-- Security Auditor's latest perspective --
I’ve discussed with the larger team and we all believe it’s a valid attack. As PortSwigger mentions in his first paragraph, while theoretically since you set the content-type to x-amf, and would hope it won’t render in the browser, most browsers will ignore this request and render it anyway. I think the vendors are relying heavily on the fact that the content-type is set; however popular browsers like IE and some versions of Safari will ignore this.
The attack can easily be triggered by exploiting CSRF or any other form of initiating an XSS attack.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您似乎已经在这里回答了您自己的疑问。
因此，您有一个服务器端实现，它将参数传递给 amf 函数调用，并将输入数据包含在返回的输出中的某个位置。
我意识到这在很大程度上是一种理论上的攻击，因为它涉及到让有效负载由浏览器呈现，而不是进入 amf 客户端。甚至可能需要浏览器/插件中的其他漏洞才能实现这种情况。也许通过 gateway.php 或类似的方式发布 CSRF 会很容易被滥用，只要浏览器将输出处理为 html/js。
但是，除非您需要调用者能够将尖括号传递到响应中，否则只需对它们进行 html 编码或剥离，这种攻击场景就会消失。
不过这很有趣。通常，人们只会为数据的预期使用者执行输出编码，但有趣的是，考虑到浏览器通常可能是一种特殊情况。这确实是一种极端的情况，但我完全支持人们养成对不可信输入进行清理和编码的习惯。
这在很多方面让我想起了跨协议注入可以用来滥用smtp等协议的反射能力，在浏览器中实现XSS的方式。请参阅http://i8jesus.com/?p =75
You seem to have answered your own queries here.
So you have a server side implementation that takes the arguments to an amf function call and includes the input data somewhere in the returned output.
I appreciate that this is largely a theoretical attack as it involves getting the payload to be rendered by the browser and not into an amf client. Other vulnerabilities in browsers/plugins may be required to even enable this scenario. Maybe a CSRF post via the likes of a gateway.php or similar would make this pretty easy to abuse, as long as the browser processed the output as html/js.
However, unless you need the caller to be able to pass-through angle brackets into the response, just html-encode or strip them and this attack scenario dissapears.
This is interesting though. Normally one would perform output-encoding solely for the expected consumer of the data, but it is interesting to consider that the browser could often be a special case. This really is one hell of an edge-case, but i'm all for people getting into the habit of sanitising and encoding their untrusted inputs.
This reminds me, in many ways, to the way that cross-protocol injection can be used to abuse the reflection capabilities of protocols such as smtp to acheive XSS in the browser. See http://i8jesus.com/?p=75
我无法解释有人会如何利用这个“漏洞”。
但是，您能否通过 HTTPS 连接而不是直接 HTTP 传递数据来解决令他们满意的问题？假设您的服务器上安装了 SSL 证书并启用了 HTTPS，这应该是您编译到 Flex 应用程序中的 services-config.xml 文件中的一个小更改。
我联系了我的一位 Adobe 同事，希望他能提供更多见解。
I can't explain how someone would take advantage of this "vulnerability".
But, can you solve the issue to their satisfaction by passing data over an HTTPS connection instead of straight HTTP? Assuming you have an SSL certificate installed on your server and HTTPS enabled, this should be a minor change in the services-config.xml file that you compile into your Flex Application.
I pinged an Adobe colleague of mine in hopes that he can offer more insight.
我认为这是一个有效的攻击场景。相关的攻击是 GIFAR，其中 JVM 被愚弄将 gif 文件视为 jar。另外，我不认为输出编码是解决问题的正确方法。
攻击的前提是欺骗浏览器，使其认为 AMF 响应是 HTML 或 Javascript。这是可能的，因为名为 MIME 类型检测，本质上是浏览器在说“开发人员可能不知道内容类型，我会扮演上帝并（可能是错误的）找出 MIME 类型”。
为了使其发挥作用，需要满足以下条件 -
那么，如何预防呢？
最好首先确保攻击者无法发出请求。一种非常简单有效的方法是在发出 AMF 请求时添加 http 请求标头，检查其在服务器上是否存在，如果不存在则拒绝该请求。该值可以是硬编码值并且不需要保密。这是可行的，因为没有已知的方法可以通过标准 html 技术添加自定义请求标头。您可以通过 XmlHttpRequest 或 flash 或 silverlight 来执行此操作，但浏览器不会为您解释内容类型，所以没关系。
现在，我对 AMF 不太了解，但如果它已经添加了请求标头 - 那么这种攻击场景是不可能的。如果不是，添加一个也很简单。
HTML 转义内容并不是一个好的解决方案。据称，有多种方法可以诱骗浏览器认为响应实际上是 HTML。换句话说，恶意输入不需要是格式良好的 HTML。尝试用谷歌搜索 mime sniffing，你应该能够找到各种欺骗浏览器的方法。
I think it is a valid attack scenario. A related attack is GIFAR, where the JVM is fooled to treat a gif file as a jar. Also, I don't think output encoding is the right way to solve the problem.
The premise of the attack is to fool the browser into thinking the AMF response is HTML or Javascript. This is possible because of a feature called MIME Type Detection, which is essentially the browser saying "Developers may not know about content-types, I will play god and (possibly incorrectly) figure out the MIME type".
In order for this to work, the following need to hold true -
<script>or<frame>or an<a>tag. Techniques like XmlHttpRequest or Flash or Silverlight don't count.So, how do you prevent it?
It is best to ensure the attacker cannot make a request in the first place. A very simple and effective way is to add a http request header while making the AMF request, check its existence on the server and deny the request if absent. The value can be a hard-coded value and need not be secret. This works, because there is no known method of adding a custom request header via standard html techniques. You can do so via XmlHttpRequest or flash or silverlight, but then the browser will not interpret the content-type for you, so its okay.
Now, I don't know much about AMF, but if it is already adding a request header - then this attack scenario is not possible. If it isn't, its trivial to add one.
HTML escaping the content is not a good solution. Allegedly, there are various ways to trick the browser into thinking the response is actually HTML. In other words, the malicious input need not be well formed HTML. Try a google search on mime sniffing, you should be able to find various ways to trick the browser.
我不知道如何可能更改 AMF 响应流中的数据，但您可能希望确保您的端点无法通过与浏览器和/或 JavaScript 的通信进行操作。查看这篇文章 恶意数据注入部分。
I don't know how possible it is to alter data within an AMF response stream, but you might want to ensure that your endpoints cannot be manipulated through communication with the browser and/or JavaScript. Check out this article under the Malicious data injection section.
这不可能是 JavaScript 注入，因为 Flash Player 中的什么会解释 JS？如果我们在播放器中提供原生 JS 甚至 json 支持，那么 Flash 社区将会欣喜若狂。 ActionScript 没有 eval 函数，更不用说 javascript
让我们假设它们意味着您可以使用 ActionScript 注入它。 AMF 协议不发送代码，它以原始类型或通用或类型化对象的形式发送数据模型。可能发生的最糟糕的事情是他们分析您的模型并添加额外的数据。这将非常困难，因为您无法注入数据，但必须解析所有数据，添加新数据，解析回来并保留 AMF 标头。因为 AMF 在数据序列化中使用引用，这意味着当对象类型重复时，您必须看到第一个对象。那么引用就是一个偏移量，这意味着添加代码的机会很小，而只能更改现有参数的值。
远程对象有一个响应处理程序，用于检查数据类型并期望将这些数据类型绑定到 ui 组件或您的代码执行的任何操作。如果这些数据类型错误，您将收到错误。如果 AMF 响应序列号错误，您将收到错误消息。如果 amf 数据报中有任何内容不完美，您将收到错误。
远程对象自动重试。如果“注入”代码花费很长时间，Flex 将重新发送一条消息并使花费很长时间的消息无效。
只是我的两分钱。作为一名 AMF 开发人员，我经常希望能够轻松地使用 amf 数据报进行调试和测试。不幸的是你会得到一个错误。
韦德·阿诺德
It could not be a JavaScript injection, as what in the Flash Player would interpret JS? The flash community would be ecstatic if we had native JS or even json support in the player. There is no eval function for actionscript let alone javascript
Let's assume they meant you could inject it with actionscript. The AMF protocol does not send code, it sends data models in the form of primitive types or generic or typed objects. The worst thing that could happen is that they analyze your model and add additional data. This would be amazingly difficult to do as you would not be able to inject the data but would have to parse all the data, add the new data, parse it back and keep the AMF headers. Because AMF uses references in it's data serialization which means that when duplicate object types you would have had to of seen the first object. The reference is then an offset which means little chance of adding code but only changing values to existing parameters.
The remote object has a response handler that is checking for the data types and expects to bind those data types to ui components or whatever your code does. If those data types are wrong you will get an error. If the AMF response sequence number is wrong you will get an error. If anything is not perfectly formed in the amf datagram you will get an error.
Remote object automatically retry. If the "injecting" code takes to long Flex will resend a message and invalidate the one that took to long.
Just my two cents. As an AMF developer I have frequently wished it was easy to screw with the amf datagram for debugging and testing. Unfortunately you will get an error.
Wade Arnold