OAuth协议更新到1.0a

上个月24号发布了针对上次那个漏洞修补的更新版协议1.0a。协议本身已经是最终的版本了,但暂时还没有合并到OAuth的官网中,按邮件列表中的说法是因为还有一些license的工作要做。下面简单说一下这次的修补。

首先回顾一下针对上次漏洞的攻击:

  1. 攻击者到一个合法的Consumer站点获得一个request token
  2. 利用trap site让受害者授权这个request token
  3. 之后针对callback的不同,有几种不同的处理方法:
    1. 如果Provider站点对第二步(请求用户授权)中的callback没有限制,那么攻击者可以利用trap site将callback设为自己的站点,然后通过这个callback判断受害者何时完成授权。等到受害者授权后,攻击者访问合法的callback来获得受害者的access token
    2. 其他的情况下(使用预定义的静态callback、没有callback由用户手工完成授权),那么攻击者和受害者之间进行竞争,当攻击者恰好在受害者授权和访问callback的间隙访问合法的callback,那么攻击者就获得了受害者的access token

接下里来看这次协议对于漏洞的修补:

  1. 1.0协议中callback在oauth认证的第二步(请求用户授权)中通过url参数设置并明文传输。新的1.0a协议中,callback作为oauth第一步(获取request token)的参数(oauth_callback),并参与到签名过程。此外当没有callback时,callback值必须设为oob(out-of-bound)。
  2. Provider在返回request token的同时,返回一个oauth_callback_confirmed参数,其值为true,表示Provider支持1.0a协议。
  3. 用户完成授权后,Provider在redirect到callback时,提供一个新的oauth_verifier参数(无法被猜测的随机字串),该参数会被用在request token换取access token的过程中。如果callback值为oob,那么Provider需要提供页面显示oauth_verifier参数值。而Consumer可以引导用户将这个参数值填入适当位置,来完成授权。

问题的解决:

  1. 通过预先指定callback,并将其作为request token的一部分,可以避免3.1中,攻击者假造callback的情况
  2. 通过oauth_verifier参数,可以避免3.2中,攻击者和受害者竞争访问callback页面的问题。(在使用预定义静态callback或者无callback的情况下,callback无法对攻击者保密。但因为攻击者无法获知oauth_verifier参数值,因此无法换取access token)

协议本身很长,主要修改集中在第6节。此外原先的附录B现在转正成为第11节并增加了一些新的安全建议。

这里还有一些概略的介绍本次修补的文档:An Idiot’s Guide to OAuth 1.0aMoving from OAuth 1.0 to OAuth 1.0a

恩,大抵如此。学术完毕,好累。。。囧。。。