前言

之前挖SRC时碰到的两个案例，账户劫持，利用方式略有区别，觉得挺有意思能学到东西。

案例一

这个案例是一个app，因为它客户端webview的配置错误，导致cookie外带，只要扫码就能获取到对应用户的cookie，达到账户劫持的目的。
首先进入app发现存在扫码功能。

先构建一个网站静态页面，包含获取cookie代码：

生成二维码用于扫描。

直接使用app扫码，没有跳转提示是否访问，直接跳转到对应页面访问，并获取到cookie：

此时可以调用app端的接口，但需要注意Authorization中的token，其中的logintoken可从上面的cookie中获取：

研究后发现Authorization的值通过接口获取,可以在登录的时候获取，只需要一些设备参数,时间戳即可，这里没有去逆向他的签名，因为不重要：

替换Authorization的值为响应中的access_token，皆可以获取到当前用户信息：

进一步在app中的内置很多内容是通过webview打开的，用到的cookie与获取到的一样
例如下面的获取订单接口的cookie与获取到的cookie是一样的：

案例二

这个案例是一个在线的课堂，扫码登录处的问题，导致点击链接登录劫持。
先在一个浏览器登录一个账号：

另一处打开登录界面刷新二维码，使用扫码登录：

生成二维码的请求如下，其中关键参数为token是后面快捷登录要用到的：

继续app扫码登录，发现需要再点击一次确认，抓包发现请求如下：

尝试修改请求为GET，发现仍然可以请求成功并登录：

那么整条链路就完成了，攻击者先本地生成二维码，获取token。
构造链接 https://xxx.com/xxx/ssologin?xxxx=xxxx&token=xxxxxtoken 。
发送给登录该站点的受害者。

受害者访问，攻击者成功劫持登录。

总结

都是一些细节上处理的不好导致的一系列登录处，扫码功能存在风险，细心去测都是能发现问题的。

---

• Previous
  safari调试小而美的小程序