背景
攻防演练中，蜜罐普及率越来越高，防守方往往使用web蜜罐，结合第三方站点存在jsonp漏洞，来抓取攻击方的ID来进一步溯源反制。
原理
假设百度某个接口存在jsonp漏洞，防守方可在web蜜罐页面上，加载一个js，由于js请求可跨域，即可向存在jsonp漏洞的xx.baidu.com/xx发请求。
如果访问者存在baidu.com的登录态，那么这个请求是能自动带上baidu.com的cookie的，响应中会有回调函数以及json格式封装的数据。
- 如下即为某个大型第三方网站某接口存在jsonp漏洞，可利用该接口获取用户名
- 具体到web蜜罐中应用，就是在某个js中写入1中提到的逻辑，然后受害者访问网站时候，自动加载这个js，触发到xx.baidu.com(仅以百度为例)的请求，js中拿到响应数据中的用户数据，最后再请求自己后端接口，数据入库
防御
- 从几年前开始，浏览器中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的一种。
例外
当然也有例外情况，但是结合实际攻击场景，这种情况比较少：
- 第三方网站set-cookie时，将该cookie的samesite属性设置为None
- 用户手动更改了浏览器默认设置，使samesite为lax情况下，还是会在jsonp跨域请求中，自动带上cookie
- 用户使用较低版本浏览器或不支持samesite默认为lax浏览器
-
第一种：结合实际情况，目前看下来，把cookie的samesite设置为None的很少，而且重要cookie一般都不会这么设置
-
第二种：以chrome浏览器为例，用户一般也不会手动更改这个配置项。如果chrome中要修改，可以在chrome://flags/，搜索samesite，把SameSite by default cookies设置为disabled，这样jsonp请求又会自动带上第三方cookie
-
第三种，具体各个浏览器及版本支持可参考mdn，可以看到大部分主流浏览器都是支持的：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
总结
- 从X-XSS-Protection、CSP和samesite等策略可以看出，浏览器侧安全是不断进步
- 传统的csrf攻击、jsonp攻击和使用web蜜罐溯源攻击者将会越来越困难
61
