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

后续跟进

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

巴特西

一个跨域请求的XSS漏洞

最新文章

热门文章