jsonp与CORS

参考到的文章：

https://www.cnblogs.com/soyxiaobi/p/9616011.html
https://www.cnblogs.com/chiangchou/p/jsonp.html（主要）
https://blog.csdn.net/u012207345/article/details/81744862
https://blog.csdn.net/weixin_41819731/article/details/92801815

前言

这是一个docker hfish蜜罐搭建引发，搭建完成后蜜罐记录的攻击源ip都是本地网关，找到了相似问题的解决办法【JSONP漏洞结合蜜罐】（https://blog.csdn.net/qq_42746827/article/details/109652508），然后开始研究jsonp…（前端名堂还真不少，代码嗯看）

---

更：后面又接触到广告cookie追踪，又回到跨域了

什么是JSONP？

​ jsonp是一种方法流程，用于解决跨域拦截问题

什么是跨域请求？

百度

跨域请求有啥用？

就是跨域获取或处理资源

为什么设定跨域拦截？

​ 起初是防止恶意执行js脚本导致浏览器数据泄露，比如XSS攻击，简单CSRF，这些攻击涉及正常页面注入的非法脚本或者恶意第三方链接嵌入的脚本，进一步进行跨域的非法请求，然后利用这些非法请求到的数据。
​ 而拦截之后无法利用这些非法请求到的数据做进一步操作。（或者服务器端不让获取）

跨域拦截的到底是啥，请求还是响应？

​ 拦截的是脚本（或者别的？）对响应资源的获取或处理。

部分实验：
对应数据包提示：[已拦截跨源请求：同源策略禁止读取位于…的远程资源]。
可以在浏览器看到数据包响应，但是[提示：脚本无法获取响应主体]。
查看浏览器详情提示：对CORS请求的响应缺少必需的Access-Control-Allow-Origin头，这些HTTP头决定浏览器是否阻止前端 JavaScript 代码获取跨域请求的响应。这个提示说明，虽然跨域请求到数据，但是服务端关于跨域配置不完整，浏览器自带跨域策略决定是否[阻止前端 JavaScript 代码获取跨域请求的响应]

​ 所以主要是浏览器对非同源脚本的限制，是浏览器的主动安全行为。（服务器也能主动配置策略，即CORS方法）

​ 其他：浏览器允许跨域请求的情形:IMG、LINK、SCRIPT、IFRAME…（前端标签）

jsonp过程中明确的点？

​ 过程：已知某个站点B支持被jsonp跨域访问，另一个站点A内构造好跨域数据处理脚本script_function（），跨域请求参数callback携带script_function名请求B的数据，B进行包装，返回script_function（+数据），前端浏览器就会自动调用已构造的script_function（）

​ 使用Jsonp跨域，是需要后端配合的：包装callback、数据格式是Jsonp格式，才能完成跨域请求。
​ 这样就跨域获取数据成功，想怎么处理就是脚本函数的内容了

结尾再论

这类似一个小聪明，浏览器对src请求不拦截，但是src返回不便特定处理。有了jsonp，可以在服务端允许跨域的情况下（回应callback），自定义脚本（即callback函数）处理数据。

JSONP过程：

请求方：qianduan.com 的前端程序员（页面）
响应方：houduan.com 的后端程序员（服务器）
1.请求方创建script，src指向响应方，同时传一个查询参数 ?callbackName=yyy
2.响应方根据查询参数callbackName，构造形如
（1）yyy.call(undefined, ‘你要的数据’）
（2）yyy(‘你要的数据’）
这样的响应
3.浏览器接收到相应，就会执行yyy.call(undefined,'你要的数据’)

JQuery对其进行的封装，因为调用形式很像ajax，所以JQuery将JSONP封装进ajax中，但请注意!JSONP与ajax不一样！
    ajax：核心是通过XmlHttpRequest获取非本页内容
    JSONP：核心是动态添加<script>标签来调用服务器提供的js脚本。

+++++++板块分隔线+++++++

以下内容参考链接：

跨域资源共享 CORS 详解

JSONP劫持&CORS跨源资源共享漏洞

CORS（跨域资源共享）错误配置漏洞的高级利用

生命在于学习——Jsonp漏洞

JSONP漏洞简介

Jsonp劫持的原理。我们考虑这样一种情况，存在两个网站A和B，用户在网站B上注册并且填写了自己的用户名，手机号，身份证号等信息，并且网站B存在一个jsonp接口，用户在访问网站B的时候。这个jsonp接口会返回用户的个人信息，并在网站B的html页面上进行显示。如果网站B对此jsonp接口的来源验证存在漏洞，那么当用户访问网站A时，网站A便可以利用此漏洞进行JSONP劫持来获取用户的信息（是不是很像CSRF）。所以jsonp本身不是漏洞，涉及它的不安全配置容易产生漏洞。

使用web蜜罐，结合第三方站点存在jsonp漏洞，来抓取攻击方的信息…

假设百度某个接口存在jsonp漏洞，防守方可在web蜜罐页面上，加载一个js，由于js请求可跨域，即可向存在jsonp漏洞的xx.baidu.com/xx发请求。
如果访问者存在baidu.com的登录态，那么这个请求是能自动带上baidu.com的cookie的，响应中会有回调函数以及json格式封装的数据。

…其实jsonp攻击也是csrf的一种。

当然已经有了相应防御措施…

考虑这种情况，我们不进一步对第三方网站进行信息获取，仅获取本地浏览器

下面是其中一种方法：

从几年前开始，浏览器中cookie新增了一个属性：samesite。这个属性出现，就是为了解决csrf和jsonp这类前端攻击。samesite介绍：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
samesite不再展开介绍，简单说来，浏览器默认设置和后端默认set-cookie情况下，cookie的samesite属性默认为lax：即在a.com域下，通过jsonp这种方式，请求b.com，将不会再自动带上b.com的cookie。
以下官方介绍很清楚了，其实jsonp攻击也是csrf的一种。

cookie 最初被设计成了允许在第三方网站发起的请求中携带（万恶之源），CSRF 攻击就是利用了 cookie 的这一“弱点”，防止 CSRF 攻击的办法已经有 CSRF token 校验和 Referer 请求头校验。
为了从源头上解决这个问题，Google 起草了一份草案来改进 HTTP 协议，那就是为 Set-Cookie 响应头新增 SameSite 属性，它用来标明这个 cookie 是个“同站 cookie”，同站 cookie 只能作为第一方 cookie，不能作为第三方 cookie。
Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。

SameSite 是由网站决定是否开启的，它针对的是某个网站下的单个 cookie。

当然，SameSite只是CSRF等跨域问题解决方案之一，大部分企业项目里都已经采用其他 CSRF 防范方式规避了该问题，而 Lax 配置又存在着兼容性问题，不能让我们完全免顾 CSRF 之忧。

其他：

set-cookie参数介绍:
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie

SameSite:不允许跨域携带cookie；利好防范csrf攻击，

HttpOnly：如果 HTTP 响应头中包含 HttpOnly 标志，则客户端无法通过客户端脚本访问 cookie（如果客户端浏览器支持此标志。）；利好防范xss攻击，不利好防范csrf攻击。

Secure：当secure属性设置为true时，cookie只有在https协议下才能上传到服务器，而在http协议下是没法上传的。非安全站点（http:）已经不能再在 cookie 中设置 secure 指令了；利好防范cookie窃听

传统的csrf攻击、jsonp攻击和使用web蜜罐溯源攻击者将会越来越困难。

JSONP漏洞挖掘、利用与防御

挖掘

方法一：GoogleHacking语法site:target.com inurl:?callback

方法二：浏览器-调试-搜索关键字（json/jsonp/callback）

好像都是在排查，排查站点是否被非法注入。。

防御

referer校验/过滤增加CSRF Token。

cookie的SameSite属性，限制cookie跨域使用。

cookie设置httponly属性后，没办法被js读取。

好像都是服务端防御。。

所以不能使用来历不明浏览器。

思考：大部分软件或app自带浏览器引擎，如果这部分跨域策略出了问题…

+++++++小分隔线+++++++

CORS介绍

参考：跨域资源共享 CORS 详解

​ JSONP劫持&CORS跨源资源共享漏洞

CORS请求默认不发送Cookie和HTTP认证信息。

如果要把Cookie（或其他跨域资源）发到其他服务器，一方面要源服务器同意，指定Access-Control-Allow-Credentials字段。另一方面，开发者必须在AJAX请求中打开withCredentials属性。否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

简单请求：

请求头添加Origin字段说明是跨域且声明源域；同意跨域则返回带有许可字段的头信息；

非简单请求：

有预检请求，浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

与JSONP区别：CORS它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。而JSONP底层是使用script标签去接受请求，只能GET方式请求，服务端返回一个回调函数的调用。

CORS漏洞检测、利用与防御

漏洞原理：多是CORS配置出现漏洞

其他参考：CORS配置错误检测方法

防御方式，同时对应漏洞成因：

• 关闭不必要开启的CORS
• 白名单限制：定义“源”的白名单，避免使用正则表达式，不要配置 Access-Control-Allow-Origin 为通配符 * 或 null ，严格效验来自请求数据包中的 Origin 的值
• 仅允许使用安全协议，避免中间人攻击
• 尽可能的返回 Vary: Origin 头部，以避免攻击者利用浏览器缓存进行攻击
• 避免将 Access-Control-Allow-Credentials 标头设置为默认值 true ，跨域请求若不存在必要的凭证数据，则根据实际情况将其设置为 false
• 限制跨域请求允许的方法，Access-Control-Allow-Methods 最大限度地减少所涉及的方法，降低风险
• 限制浏览器缓存期限：建议通过 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers 头部，限制浏览器缓存信息的时间。通过配置 Access-Control-Max-Age 标头来完成，该头部接收时间数作为输入，该数字是浏览器保存缓存的时间。配置相对较低的值，确保浏览器在短时间内可以更新策略
• 仅在接收到跨域请求时才配置有关于跨域的头部，并确保跨域请求是合法的源，以减少攻击者恶意利用的可能性。

检测：参考CORS跨域漏洞的学习

CORS的漏洞主要看当我们发起的请求中带有Origin头部字段时，服务器的返回包带有CORS的相关字段并且允许Origin的域访问。

一般测试WEB漏洞都会用上BurpSuite，而BurpSuite可以实现帮助我们检测这个漏洞。

首先是自动在HTTP请求包中加上Origin的头部字段，打开BurpSuite，选择Proxy模块中的Options选项，找到Match and Replace这一栏，勾选Request header 将空替换为Origin:foo.example.org的Enable框。

然后我们就可以开始去访问我们认为有漏洞的网站，访问足够多后在BurpSuite的Proxy模块下的HTTP history来筛选带有CORS头部的值。

CORS结合XSS漏洞进行利用

有时候CORS配置了信任自身的任意子域，那么如果一个子域存在XSS漏洞就可以通过这个漏洞去读取其他子域的资源，类似的场景还有比如HTTPS域信任HTTP域等。

关于CORS配置漏洞扫描

github上提供了一个关于扫描CORS配置漏洞的脚本：

https://github.com/chenjj/CORScanner

CSRF与CORS漏洞的区别

相同点：都需要借助第三方网站都需要借助AJAX都需要用户登陆

不同点：第三方网站可利用CORS漏洞读取受害者的敏感信息；第三方网站可利用CSRF漏洞代替受害者执行敏感操作

靶场及POC

JSONP

靶场：DoraBox - 多拉盒

CORS

bWAPP靶场