我们的一些客户已经在我们所有的JSONP端点中发现了一个XSS漏洞,但我不同意它是否真正构成了漏洞。希望获得社区的意见,以确保我没有错过任何事情。

因此,与任何jsonp系统一样,我们有一个端点,例如:

http://foo.com/jsonp?cb=callback123

在响应中重播cb参数的值:
callback123({"foo":"bar"});

客户提示说我们没有在CB参数中过滤掉HTML,因此他们会设计一个这样的示例:
http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--

显然,对于返回text/html内容类型的URL而言,这会带来一个问题,其中浏览器呈现HTML,然后在onload处理程序中执行潜在的恶意javascript。可以用来窃取Cookie并将其提交到攻击者的网站,甚至可以生成用于网络钓鱼的虚假登录屏幕。用户检查了该域,并发现该域是他信任的域,因此他进入了年龄并登录。

但是,在本例中,我们将内容类型 header 设置为application/javascript,这在不同的浏览器中导致各种不同的行为。即Firefox仅显示原始文本,而IE则打开“另存为...”对话框。我认为这两个都不是特别可利用的。 Firefox用户不会阅读恶意文本,告诉他跳下桥并认真思考。 IE用户可能会被另存为对话框和单击取消所迷惑。

我想我会看到一种情况,即IE用户被诱骗保存并打开.js文件,然后该文件通过Microsoft JScript引擎并获得对该用户计算机的各种访问权限。但这似乎不太可能。这是最大的威胁,还是我错过了其他漏洞?

(很明显,我将通过过滤以仅接受有效的javascript标识符来进行“修复”,以防万一,长度限制,以防万一;但是我只是想就我可能错过的其他威胁进行对话。)

最佳答案

他们的注入(inject)必须像</script><h1>pwned</h1>
验证$_GET['callback'](假设PHP)是有效的JavaScript函数名称,对您来说比较琐碎。

JSONP的要点是绕过浏览器的限制,这些限制会尝试防止XSS类型的漏洞,因此在某种程度上,JSONP提供程序和请求站点之间需要信任。

但是,只有在客户端没有很好地处理用户输入时,才会出现该漏洞-如果他们对所有JSONP回调名称进行硬编码,那么就没有潜在的漏洞。

10-07 19:16
查看更多