Mik*_*lin 6 javascript security xss jsonp
我们的一些客户已经知道我们所有JSONP端点中存在感知的XSS漏洞,但我不同意它是否真的构成了漏洞.想要得到社区的意见,以确保我没有遗漏一些东西.
因此,与任何jsonp系统一样,我们有一个端点,如:
http://foo.com/jsonp?cb=callback123
其中cb参数的值在响应中重放:
callback123({"foo":"bar"});
客户抱怨我们没有过滤掉CB参数中的HTML,所以他们会设计一个这样的例子:
http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--
显然,对于返回内容类型的URL text/html,这会产生一个问题,即浏览器呈现该HTML然后在onload处理程序中执行潜在的恶意javascript.可用于窃取cookie并将其提交给攻击者的网站,甚至可以生成虚假的网络钓鱼登录屏幕.用户检查域并发现它是他信任的域名,因此他会使用agead并登录.
但是,在我们的例子中,我们设置的内容类型标头application/javascript会导致不同浏览器中的各种不同行为.即Firefox只显示原始文本,而IE打开一个"另存为..."对话框.我认为其中任何一个都不是特别可利用的.Firefox用户不会阅读恶意文本,告诉他跳过桥梁并思考其中的大部分内容.并且IE用户可能会被"另存为"对话框混淆并点击"取消".
我想我可以看到IE用户被欺骗保存并打开.js文件的情况,然后该文件通过微软JScript引擎获取对用户机器的各种访问权限; 但这似乎不太可能.这是最大的威胁还是我错过了一些其他漏洞？
(显然我要通过过滤来"修复"只接受一个有效的javascript标识符,只有一些长度限制,但我只想要一个关于我可能错过的其他威胁的对话框.)
如果是这样的话，没有什么可以阻止他们做一些插入代码的事情。
想象一个 URL，例如http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };foo. 当客户端收到此消息时，根据您处理 JSONP 的方式，您可能会引入运行任意复杂度的 JS 的能力。
至于这是一个攻击向量：想象一个 HTTP 代理，它是除 之外的所有 URL 的透明转发代理http://example.com/jsonp，它采用查询字符串的 cb 部分并在其前面添加一些恶意 JS，然后重定向到该 URL。