OAuth笔记

协议参考

1.0a http://tools.ietf.org/html/rfc5849

译文:http://www.rollingcode.org/blog/f/oauth-core-1.0-final-cn.html,这是1.0的,不是1.0a的

2.0 http://tools.ietf.org/html/draft-ietf-oauth-v2-23

译文:http://wenku.baidu.com/view/b37ed7260722192e4536f66e.html


OAuth 1.0a流程


OAuth 1.0a安全考虑

  1. RSA-SHA1 Signature Method ,签名不要用client共享私钥,这样会完全依赖于client私钥的安全性。(使用client凭据,获得临时凭据,这时会验证client,不仅凭密钥)
  2. Confidentiality of Requests ,请求内容的私密性,防止偷听。(https)
  3. Spoofing by Counterfeit Servers ,协议没有认证server的身份,需要通过其他方式认证server的身份
  4. Proxying and Caching of Authenticated Content ,通过http缓存头,保护内容。
  5. Plaintext Storage of Credentials,共享密钥,由于需要签名用,所以是明文保存的。要防止被窃取。
  6. Secrecy of the Client Credentials client,凭据,不仅仅通过共享私钥验证,防止私钥泄露,也要加上ip等其他方式,验证client
  7. Phishing Attacks,owner用多了这种重定向输入密码的情况,会习惯被重定向到一个页面,输入用户名和密码。容易被钓鱼。server要训练owner如何识别真伪
  8. Scoping of Access Requests, 协议没有关于access的范围,实现者应该考虑控制access的粒度,比如access只能访问某些资源
  9. Entropy of Secrets,除非使用ssl,否者就会被偷听(访问client时可能不是,server都是ssl的),让攻击者重用凭据。所以要产生随机密钥足够长,在合理的时间内,攻击者无法恢复凭据。
  10. Denial-of-Service / Resource-Exhaustion Attacks,协议的一些规定会可能会造成服务器资源耗尽或拒绝攻击,比如跟踪nonces ,判断nonce是否被使用过,如果短时间内大量nonce发送过来,会导致资源耗尽。还有签名算法,短时间内大量错误签名发送过来,会造成拒绝服务。server需要考虑,oauth协议引入的新的攻击点,并阻止这些风险
  11. SHA-1 Cryptographic Attacks ,SHA-1有一些算法上的不足,需要考虑sha-1是否能够提供足够的安全性。SHA-1 with the Hash-based Message Authentication Code (HMAC) and should not affect the "HMAC-SHA1" signature method, it may affect the use of the "RSA-SHA1" signature method.  NIST has announced that it will phase out use of SHA-1 in digital signatures by 2010
  12. Signature Base String Limitations,协议签名串没有覆盖整个http请求,比如一些请求头信息,没有定义参数顺序。需要额外机制来保证这些信息。
  13. Cross-Site Request Forgery ,防止跨站攻击超出本协议范围,client和server都需要防止跨站攻击,跨站攻击可以获得owner授权而不需要owner同意
  14. User Interface Redress ,防止用户操作界面被修改,比如clickjacking
  15. Automatic Processing of Repeat Authorizations,自动授权,owner已经受过权,client第二次重定向到server时,server自动重定向回client。如果client默认接受,就会有风险。攻击者就会偷取凭据重定向一个已授权的请求到server,server自动授权访问资源。取消自动授权,owner显式同意授权。

OAuth 2.0流程


OAuth2.0安全考虑

  1. Client Authentication,authorization server要提供比较强的client认证,不仅仅只是密码。还需要防止其他凭据暴露给未认证的client
  2. Client Impersonation,authorization server必须认证client,如果client本身就无法认证,必须注册明确的URI接收授权信息,或者用其他方式保护受限资源,防止恶意的client
  3. Access Tokens Access,Tokens在传输和存储中必须保密,Access Tokens 不能被未认证的第三方产生,修改,猜测出有效的token。Access Tokens 应该在比较小的范围和生命周期内。应该认证client,保证产成给相同client。
  4. Refresh Tokens,同上
  5. Authorization Codes,同上
  6. Authorization Code Redirection URI Manipulation,authorization server必须验证Redirection URI和产生authorization code时是相同的
  7. Resource Owner Password Credentials,尽量少用The resource owner password credentials grant type
  8. Request Confidentiality,敏感参数不要在不安全的网络传输
  9. Endpoints Authenticity,为了防止中间人攻击,the authorization server必须用TLS,client必须认证uthorization server的TLS证书
  10. Credentials Guessing Attacks,The authorization server 必须阻止猜测 access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials.
  11. Phishing Attacks,同1.0
  12. Cross-Site Request Forgery,同1.0
  13. Clickjacking,应用应该用新窗口,让终端用户授权,而不是嵌入式的窗口
  14. Code Injection and Input Validation,Authorization server and client必须检查任何接收到的值
  15. Open Redirectors,重定向参数如果没有验证的话,会被修改成错误的地址
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值