我会惊讶地看到一个AMF库编码响应数据,氟肯定不会.似乎PortSwigger和IBM AppScan等安全应用程序将这种类型的测试包含在其工具箱中.您是否遇到过AMF的漏洞,可以解释XSS问题如何显现？只是好奇.如果有争论存在或修补漏洞,我需要争辩我的出路.考虑到Flex的AMF使用,我以为你可能有一些洞察力.
附加信息 …
所以从实际的供应商PortSwigger这一点.我向他们提出了这个问题,网,他们承认这种攻击是非常复杂的.最初他们把这个分类为高严重性安全问题,但我认为他们的调整现在正在改变.我以为我会把你的答复的内容发贴给大家,因为我认为这个观点是非常有趣的.
—来自PortSwigger的问题—
谢谢你的消息.我认为答案是这可能是一个
脆弱性,但不是微不足道的利用.
你说得对,在响应消耗的时候不会出现这个问题
AMF客户端(除非它有愚蠢的事情),而是攻击者可以
设计响应由浏览器使用的情况.最
浏览器将忽略HTTP Content-Type标头,并将会查看
实际的响应内容,如果它像HTML一样看起来会愉快
处理它这样.历史上,人们已经存在许多攻击
在其他响应格式(XML,图像,其他)中嵌入HTML / JS内容
应用程序内容),并且这是通过浏览器执行的.
所以问题的反应格式不是太多,而是反应的
要求生成的请求的格式.这不算什么
攻击者设计一个包含有效的AMF消息的跨域请求.
类似的事情就是包含XSS的XML请求/响应
行为.当然可以创建一个有效的XML响应
由浏览器作为HTML处理,但挑战是如何发送原始XML
HTTP身体跨域.这不能使用标准的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攻击来触发.
解决方法
因此,您有一个服务器端实现,将参数传递给amf函数调用,并将输入数据包含在返回的输出中的某处.
我明白,这主要是理论上的攻击,因为它涉及使有效载荷由浏览器呈现,而不是amf客户端.甚至可能需要浏览器/插件中的其他漏洞,甚至可以启用此方案.只要浏览器将输出处理为html / js,就可以通过一个gateway.PHP或类似的CSRF文章来实现这一点.
但是,除非您需要调用方能够将尖括号传递到响应中,否则仅使用html编码或剥离它们,并且此攻击场景消失.
这很有趣.通常情况下,只能对数据的预期消费者执行输出编码,但有趣的是,浏览器通常可能是一种特殊情况.这真的是一个边缘案件的一个地狱,但我都是为了人们习惯于消毒和编码他们的不信任的投入.
这让我想起在许多方面,跨协议注入可以用来滥用诸如smtp之类的协议的反射功能来在浏览器中实现XSS.见http://i8jesus.com/?p=75
