DE演示站

时间:2020-04-22 01:19  编辑:admin

  在比来参与的一次对站点A的众测中,我发明A可以应用QQ账号停止上岸。在过去的几个月里,我发清晰明了少量关于OAuth上岸劫持的破绽,假设你有兴味,可以参考:OAuth回调参数破绽案例解析

  固然我置信目标A曾经不存在OAuth上岸劫持破绽(因为QQ曾经在redirect_uri参数上做了强校验),然则我仍计划对它的上岸流程一寻找竟。

  下面,我以A.com代表目标A的域名来展现我是如何发明一个账号劫持破绽的。

  翻开A的QQ上岸链接后,我发清晰明了一些奇妙的事。

  

  如上图,redirect_uri并没有指向A.com,而是指向了B.com。将参数URL解码,

  

  不难推测,这里触及到2次跨域上岸:

  在扫尾曾经说过,QQ曾经对redirect_uri参数做了强校验,要想劫持到B.com的上岸账号曾经不太能够。所以,我的目标放在了s_url这个参数上。

  复杂剖析一下上岸流程就可以发明s_url是若何任务的。

  (a) 起首,用户应用QQ账号上岸到B.com;

  (b) 然后B.com发送以下恳求,获得token,并引诱用户携带token跳转到A.com;

  

  (c) A.com验证token是正当的,则种下cookie。

  

  至此,用户胜利上岸到A.com。

  从全部上岸流程来看,只需我们能想方法盗取到token,就可以劫持用户的上岸账号。

  我的目标是盗取到token,最直接的方法固然是修改参数s_url,让用户携带token跳转到恶意域名,从而泄漏token。

  

  一番测试后,我发明s_url的校验也很严厉,即使在门路前面附加一些字符,生成的跳转链接中都不会携带token。

  

  经过一些fuzz后,我发明我仿佛能在最后一个字符前面附加一些符号。

  

  我可以在s_url的开头附加3种符号,而不影响token的生成,辨别是:

  让我眼前一亮,尽人皆知,URL中的将被浏览器视作锚点,厥后的数据不会发送到效劳器。

  

标签: