一个跨域请求的XSS漏洞

    场景回顾

    一个表单进行跨域提交的方式有很多,我们使用的采用隐藏iframe,在本域下放一个代理页面,通过服务端配合完成一次完整的请求。

    首先,部署proxy.html代理页面。这个页面处理服务端返回的数据,并执行接口的回调函数。接口请求成功后,返回的是:

<script>location.href='http://www.a.com/proxy.html?fun=callback&a=1&b=2&c=3';</script>

    proxy页面,解析服务端传回的参数最后执行: 

callback({

        a:1,

        b:2,

        c:3

    });

    这样就完成了一次,接口请求并且在请求成功后,执行回调。

    其次,页面上需要有一个隐藏的iframe,把请求发到这个页面,然后接受返回值。

    整体上是这么一个过程,实现了post请求的跨域提交。 

    proxy.html的代码:

<!doctype html>
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><script type="text/javascript">
(function(){
		var queryStr = location.search.substring(1).split('&'),oneQueryStr,args = {},g = top,scope = top ,callback;
		for(var i in queryStr){
			oneQueryStr = queryStr[i].split('=');
			if(!callback && oneQueryStr[0] == 'fun'){
				callback = oneQueryStr[1];
			};
			if(oneQueryStr[0]&&oneQueryStr[1]){
				args[oneQueryStr[0]] = (oneQueryStr[1]||'').replace(/[><'"{}]/g, '');
			}

		}
		callback = callback.split('.');

		if( callback[0] === 'document' 
			|| callback[0] === 'location' 
			|| callback[0] === 'alert'){
		}else{
			for(var i = 0,len= callback.length;i<len;i++){
				if(i==0 && callback[0]=="parent"){
					g = parent;
					scope = parent;
				}else if(i==0 && callback[0]=="top"){
					g = top;
					scope = top;
				}else{
					if(i<len-1){
						scope = scope[callback[i]];
					}
					g = g[callback[i]];
				}
			}

			g.call(scope,args);
		}
	
})();
</script>
</body></html>

    XSS漏洞

    很显然,既然页面上执行了接口返回的数据。那么就必须对返回的数据进行过滤,这样才能防止恶意的代码进行攻击。

    看了上面proxy.html的代码我们发现,已经处理了fun这个参数的值,不能为alert、document、location这些值。这是通过黑名单机制来进行判断的,一旦命中就无法执行。但是一直存在这么一个问题:我们能防的只是我们所了解的XSS漏洞,如果我们不知道,就需要遇到问题,解决问题,这样显然很被动。 

    有这么一个攻击案例,即便是我们已经过滤了alert、document这些window下的方法,但是还有我们不知道的方法无法防御,这就增大了我们的维护成本。在我们业务里,带来的问题是:每次调整这个文件,整个公司的业务可能都会被牵扯进来,都要升级很被动。

    上面的这个例子就是掉用了页面上给window下扩展的$,这个变量对于前端的同学都不陌生。这个$能干的事情就更多了,简直太可怕了。这个案例只是打印了你的cookie,他可以做很多很多的事情,后果可以预想...

    解决方案

    还是要过滤fun参数,这个『万恶之源』,采用的方式的白名单+黑名单,双层防护。首先使用白名单进行过滤,白名单设置的是业务所用的函数名,其他的都不信任;其次,白名单如果验证通过后,在进行黑名单验证。为什么还需要这么异步操作呢?主要的担心有这么一个方法,白名单会通过,但是又是无用的方法,这样就可以使用黑名单在此过滤。       

    后续跟进 

    我现在的这个处理方式不一定是最好的,也可能存在问题。在这里提出,有两方面的考虑。其一:想要获得更好的方案来解决这个问题;其二:攻击和防守是一个持续的问题,需要一直跟进,逐渐找到合理的解决方案。如果有更好的方案,也希望不吝赐教!

 

 

 

posted @ 2015-04-11 20:34  黑MAO  阅读(3734)  评论(1编辑  收藏  举报