OAuth1.0 简介及安全分析
1.??概述
之后针对callback的不同，有几种不同的处理方法：
a)??????如果Provider站点对第二步（请求用户授权,图中第3步）中的callback没有限制，那么攻击者可以利用trap site将callback设为自己的站点，然后通过这个callback判断受害者何时完成授权。等到受害者授权后，攻击者访问合法的callback 来获得受害者的access token
b)??????其他的情况下（使用预定义的静态callback、没有callback由用户手工完成授权），那么攻击者和受害者之间进行竞争，当攻击者恰好在受害者授权和访问callback的间隙访问合法的callback，那么攻击者就获得了受害者的access token
解决方案1.0a的版本提供了以下改进：
1.?????? oauth_callback 在第一步即获取Request Token时（Get Request Token，图中第二步）就必须提供，如果不需要重定向，则其值必须为oob（out_of_band configuration），服务提供方此时返回参数oauth_callback_confirmed，且值为true。在第二步即验证阶段（图中第三步）不接受该参数。
2.?????? 验证完成后会返回验证码（oauth_verifier）为的是在没有callback的时候，服务提供方显示给用户，然后用户可以在第三方应用的设备上输入，标示自己已经授权（和未授权的用户分开），然后第三方应用必须加上该验证码去获取Access Token
然而实际上OAuth1.0最终版（已经成为RFC5849 标准）已经没有这个安全的漏洞了。
2.3 ???协议提及的安全考量OAuth协议（RFC5849标准）文档上提出了以下安全考量，对应http://tools.ietf.org/html/rfc5849#section-4
1.??????似乎说RSA_SHA1更安全
2.?????? 建议用SSL或者TLS保证请求的安全
3.?????? 建议用SSL或者TLS保证确认服务提供者的身份
4.??????客户端proxy或者cache的安全
5.?????? 服务端密钥的安全存储
6.??????客户端密钥的安全存储
7.?????? 警告用户，防止用户的疏忽
8.?????? 由于第三方应用的不可信任（可能希望获取更多的用户资源），需对授权的资源严格的分类，并告知明确用户可能存在的风险
9.?????? 密钥的安全性，最好是真正的随机数
10.??DOS/DDOS攻击
11.??SHA-1自身的漏洞
12.??签名只是保证了base_string的完整
13.??CSRF（Cross SiteRequest Forgery）
14.??Clickjacking
15.??客户端密钥的安全
?
上面的各条中黑体的条款，我们需要注意，其他是客户端或者用户需要防范的，我们服务提供方需要给用户足够的信息去确认授权的风险。
2.3????总结其实协议1.0定稿后，已经广泛使用，其本身不会有什么安全漏洞，但协议的实现可能存在漏洞，这是我们需要花精力去测试的。
