OAuth Core 1.0 : Appendix B. Security Considerations : 俺約/メモ

 

Appendix B.  Security Considerations




Appendix B.1.  Credentials and Token Exchange (クレデンシャルとトークン交換)

The OAuth specification does not describe any mechanism for protecting Tokens and secrets from eavesdroppers when they are transmitted from the Service Provider to the Consumer in Section 6.1.2 (Service Provider Issues an Unauthorized Request Token) and Section 6.3.2 (Service Provider Grants an Access Token). Service Providers should ensure that these transmissions are protected using transport-layer mechanisms such as TLS or SSL. (OAuthではSP->Consuerのトークンやシークレットを盗聴者からどうやって守るかは定義していません。TLS/SSLを使って守ってください。)




Appendix B.2.  PLAINTEXT Signature Method(PLAINTEXT署名方法)

When used with PLAINTEXT signatures, the OAuth protocol makes no attempts to protect User credentials from eavesdroppers or man-in-the-middle attacks. The PLAINTEXT signature algorithm is only intended to be used in conjunction with a transport-layer security mechanism such as TLS or SSL which does provide such protection. If transport-layer protection is unavailable, the PLAINTEXT signature method should not be used. (MITMAや盗聴者からは守ることができません。TLS/SSLでのみ使ってください。)




Appendix B.3.  Confidentiality of Requests(要求の機密性)

While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content. Service Providers should carefully consider the kinds of data likely to be sent as part of such requests, and should employ transport-layer security mechanisms to protect sensitive resources. (リクエストの検証方法を定めていますが、リクエストの機密性は保障しません。SPはTLS/SSLを使って機密性を担保してください。)




Appendix B.4.  Spoofing by Counterfeit Servers(偽造サーバーでだます)

OAuth makes no attempt to verify the authenticity of the Service Provider. A hostile party could take advantage of this by intercepting the Consumer’s requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services based on OAuth, and should require transport-layer security for any requests where the authenticity of the Service Provider or of request responses is an issue. (SPが正しいかどうかを検証しません。偽装サーバーが悪さできます。TLS/SSLを使うこと)

(SSLの場合は、CAの確認と、OCSPでリボケーションチェックもしましょう)




Appendix B.5.  Proxying and Caching of Authenticated Content(認証済みコンテンツのプロキシ/キャッシュ)

The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is optional. However, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers. (HTTP Authorization Schemeはオプションですが、RFC2616はAuthorizationとWWW-Authenticateヘッダーを使って認証済みコンテンツを識別しています。プロキシやキャッシュはこれらのヘッダーが無いと十分にリクエストを守ることができない。)

For example, private authenticated content may be stored in (and thus retrievable from) publicly-accessible caches. Service Providers not using the HTTP Authorization scheme (OAuth HTTP Authorization Scheme) should take care to use other mechanisms, such as the Cache-Control header, to ensure that authenticated content is protected. (たとえば、プライベートな認証済みコンテントはパブリックにアクセスできるキャッシュに入ることがありえます。HTTP認証スキームを使わないSPは慎重にこの機能を使ってください。Cache-Controlヘッダーとかをつかって認証済みコンテンツが保護されるようにしてください)




Appendix B.6.  Plaintext Storage of Credentials(クレデンシャルをプレーンテキストで保存)

The Consumer Secret and Token Secret function the same way passwords do in traditional authentication systems. In order to compute the signatures used in the non-PLAINTEXT methods, the Service Provider must have access to these secrets in plaintext form. This is in contrast, for example, to modern operating systems, which store only a one-way hash of user credentials. (Consumerシークレット、トークンシークレットは従来型の認証システムにおけるパスワードのようなもんです。署名計算するためにはSPはプレーンテキストでそれにアクセスしなければなりません。現代のOSとかは一方方向のハッシュを使っています。)

If an attacker were to gain access to these secrets – or worse, to the Service Provider’s database of all such secrets – he or she would be able to perform any action on behalf of any User. Accordingly, it is critical that Service Providers protect these secrets from unauthorized access. (攻撃者がこれらのシークレットへのアクセス、もっと悪いケースだとSPのDBのアクセス権を得てしまったら、Userに成り変って何でもできてしまいます。よって、SPはこれらのシークレットをちゃんと守ってね)




Appendix B.7.  Secrecy of the Consumer Secret(Consumerシークレットの機密性)

In many applications, the Consumer application will be under the control of potentially untrusted parties. For example, if the Consumer is a freely available desktop application, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the Consumer Secret used to authenticate the Consumer to the Service Provider. (Consumerのアプリケーションは互いに信頼されていないサイト間の元で動くことが普通です。たとえば、Consumerがデスクトップアプリだったら、攻撃者は分析のコピーをダウンロードできるに違いありません。この場いい、Consumer Secretをリカバーできてしまいます。)

Accordingly, Service Providers should not use the Consumer Secret alone to verify the identity of the Consumer. Where possible, other factors such as IP address should be used as well. (よって、SPはConsumerシークレットだけを使ってConsumerを判断してはいけません。可能であればIPアドレスをかも使いましょう?)

(うーむ。。。。。。。。。。)




Appendix B.8.  Phishing Attacks(フィッシング)

Wide deployment of OAuth and similar protocols may cause Users to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If Users are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal Users’ passwords. (OAuthのようなプロトコルが広まるとUserがパスワードを入れさせるサイトにリダイレクトされることに慣れっこになってきます。Userがクレデンシャルを入れる前にこれらのサイトの確からしさを十分に検証できないならば、攻撃者がパスワードを盗めてしまいます)

Service Providers should attempt to educate Users about the risks phishing attacks pose, and should provide mechanisms that make it easy for Users to confirm the authenticity of their sites. (SPはUserにフィッシング攻撃のリスクがあることを教育しようとしなければなりません。

(うーむ。。。。。。。。。。)




Appendix B.9.  Scoping of Access Requests(アクセス要求のスコープ)

By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer. A Consumer either has access to Protected Resources or it doesn’t. Many applications will, however, require greater granularity of access rights. For example, Service Providers may wish to make it possible to grant access to some Protected Resources but not others, or to grant only limited access (such as read-only access) to those Protected Resources. (Consumerに与えられたアクセス件のスコーピンする手段はOAuthでは提供されません。ConsumerはPRにアクセスできたり、できなかったりします。多くのアプリではアクセス権の粒度を大きく求めるのが普通です。たとえば、SPはRPのアクセス権をふさわしい人間にのみ許可したり、あるいはリードオンリーのように制限されたアクセス件を与えたりしたく思います。)

When implementing OAuth, Service Providers should consider the types of access Users may wish to grant Consumers, and should provide mechanisms to do so. Service Providers should also take care to ensure that Users understand the access they are granting, as well as any risks that may be involved. (OAuthを実装するときはSPはUserがConsumerに与えることのできるアクセスのタイプを考慮し、提供すべきです。SPはUserが付与しようとしているアクセスとそれに含まれるリスクについて十分に理解できるように勤めるべきです。)

OAuth Core 1.0

カテゴリー: 未分類 パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中