之前挖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 。
发送给登录该站点的受害者。
受害者访问,攻击者成功劫持登录。
都是一些细节上处理的不好导致的一系列登录处,扫码功能存在风险,细心去测都是能发现问题的。
如果你是一个长期主义者,欢迎加入我的知识星球(优先查看这个链接,里面可能还有优惠券),我们一起往前走,每日都会更新,精细化运营,微信识别二维码付费即可加入,如不满意,72 小时内可在 App 内无条件自助退款