上个月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.0a，Moving from OAuth 1.0 to OAuth 1.0a

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