ソース：

訳：

Web サイトにアクセスしたことがある場合は、たとえ聞いたことがなくても、OAuth に一度は遭遇したことがあるでしょう。
「Google でサインイン」ボタンを見たことがありますか? もしそうなら、OAuth に出会ったことになって。
この記事では、OAuth (特に OAuth 2.0) とは何か、およびセキュリティの観点から OAuth がどのように誤って実装される可能性があるかについて簡単に説明を。
特に、バグ報奨金調査中に実装で遭遇した多くの問題に焦点を当てて。

「クイック」プライマー

OAuth について話すときには、いくつかの異なるバージョンと、考慮すべき付与タイプがあって。
これらについて読むには、 https://oauth.net/2/ 基本的な理解を得るためにを読むことをお勧めし。
この記事では、今日遭遇する最も一般的なフローである OAuth 2.0 認証コード付与タイプに焦点を当て。
本質的に、OAuth は、アプリケーションが別のアプリケーション (認可サーバー) からデータにアクセスしたり、アカウントに対して特定のアクションを実行したりできるようにする認可メカニズムを開発者に提供し。

たとえば、Web サイト https://yourtweetreader.com に、プライベートツイートを含む、これまでに送信したすべてのツイートを表示する機能があるとして。
これを行うために、OAuth 2.0 が導入されて。
https://yourtweetreader.com では、Twitter アプリケーションがあなたのすべてのツイートにアクセスすることを承認するように求められます。
に同意ページがポップアップ表示され https://twitter.com 、どのような権限が要求されているか、およびそれを要求している開発者が誰であるかが表示されて。
リクエストを承認すると、https://yourtweetreader.com があなたに代わってあなたのツイートにアクセスできるようになり。
さて、これは非常に高レベルであり、ここにはいくつかの複雑さがあって。
この例を取り上げて、OAuth 2.0 のコンテキストで理解することが重要な特定の要素についてもう少し詳しく説明し。

resource owner: The resource owner is the user/entity granting access to their protected resource, such as their Twitter account Tweets

resource server: The resource server is the server handling authenticated requests after the application has obtained an access token on behalf of the resource owner . In the above example, this would be https://twitter.com

client application: The client application is the application requesting authorization from the resource owner. In this example, this would be https://yourtweetreader.com.

authorization server: The authorization server is the server issuing access tokens to the client application after successfully authenticating the resource owner and obtaining authorization. In the above example, this would be https://twitter.com

client_id: The client_id is the identifier for the application. This is a public, non-secret unique identifier.

client_secret: The client_secret is a secret known only to the application and the authorization server. This is used to generate access_tokens

response_type: The response_type is a value to detail which type of token is being requested, such as code

scope: The scope is the requested level of access the client application is requesting from the resource owner

redirect_uri: The redirect_uri is the URL the user is redirected to after the authorization is complete. This usually must match the redirect URL that you have previously registered with the service

state: The state parameter can persist data between the user being directed to the authorization server and back again. It’s important that this is a unique value as it serves as a CSRF protection mechanism if it contains a unique or random value per request

grant_type: The grant_type parameter explains what the grant type is, and which token is going to be returned

code: This code is the authorization code received from the authorization server which will be in the query string parameter “code” in this request. This code is used in conjunction with the client_id and client_secret by the client application to fetch an access_token

access_token: The access_token is the token that the client application uses to make API requests on behalf of a resource owner

refresh_token: The refresh_token allows an application to obtain a new access_token without prompting the user

にアクセスしhttps://yourtweetreader.com 、「Twitter と統合」ボタンをクリックします。
https://yourtweetreader.com はリクエストを https://twitter.com 、リソース所有者であるあなたに、https://yourtweetreader.com の Twitter アプリケーションがあなたのツイートにアクセスすることを承認するよう求めるに送信します。リクエストは次のようになります。

3. 同意ページが表示され。

4. 承認されると、Twitter はリクエストを返信します。 redirect_uriとともに codeそして stateパラメーター：

5. https://yourtweetreader.com がそれを受け取ります code、そして彼らのアプリケーションを使用して client_idそして client_secret、サーバーからリクエストを作成し、 access_tokenあなたに代わって、あなたが同意した権限にアクセスできるようになります。

6. 最後に、フローが完了し、 https://yourtweetreader.com が Twitter への API 呼び出しを行います。 access_tokenツイートにアクセスします。

バグ報奨金の調査結果

さて、興味深い部分です！ OAuth の実装では問題が発生する可能性が数多くあり。
私がよく見かけるバグのさまざまなカテゴリを次に示し。

弱い redirect_uri 構成

これはおそらく、OAuth 実装のバグを探すときに誰もが認識する最も一般的なことの 1 つで。
の redirect_uriなどの機密データであるため、これは非常に重要で。
code承認後にこの URL に追加され。
もし redirect_uri攻撃者が制御するサーバーにリダイレクトされる可能性があり。
これは、攻撃者が、 code自分自身を攻撃し、被害者のデータにアクセスし。

これが悪用される方法は認可サーバーによって異なり。
まったく同じものしか受け入れない人もいます redirect_uriパスはクライアントアプリケーションで指定されているとおりですが、同じドメインまたはサブディレクトリ内のすべてのものを受け入れるものもあり。 redirect_uri .

サーバーによって処理されるロジックに応じて、サーバーをバイパスするための手法が多数あって。 redirect_uri。
という状況では、 redirect_uriには次のものが含まれます。https://yourtweetreader.com /callback

オープンリダイレクト: https://yourtweetreader.com/callback?redirectUrl=https://evil.com
パストラバーサル: https://yourtweetreader.com/callback/../redirect?url=https://evil.com
弱い redirect_uri正規表現: https://yourtweetreader.com.evil.com
HTML インジェクションとリファラーヘッダーを介したトークンの盗用: https://yourtweetreader.com/callback/home/attackerimg.jpg

状態パラメータの不適切な処理

これは、OAuth 実装で最もよく見られる問題で。
非常に多くの場合、 stateパラメータが完全に省略されているか、間違った方法で使用されていて。
状態パラメータが存在しない場合、または決して変更されない静的な値の場合、OAuth フローは CSRF に対して脆弱になる可能性が非常に高くなり。
場合によっては、たとえ stateパラメータが指定されている場合、アプリケーションはパラメータの検証を行わず、攻撃が機能する可能性があり。
これを悪用する方法は、自分のアカウントで認証プロセスを実行し、認証直後に一時停止することで。
すると、次のようなリクエストが表示され。

これらのコードは通常 1 回限り使用されるため、このリクエストを受信した後はリクエストを削除でき。
この URL をログインしているユーザーに送信すると、あなたのアカウントがそのユーザーのアカウントに追加されて。
最初は、自分のアカウントを被害者のアカウントに追加しているだけなので、これはあまり慎重に聞こえるかもしれません。
ただし、OAuth 実装の多くはサインインを目的としているため、ログインに使用する Google アカウントを追加できれば、Google アカウントでログインすると以下にアクセスできるため、ワンクリックでアカウント乗っ取りを実行できる可能性があり。被害者のアカウント。

また、追加のリダイレクト値として state パラメーターが使用されているのを何度か見たことがあり。
アプリケーションは使用します redirect_uri最初のリダイレクトの場合は、その後、 stateパラメータを 2 番目のリダイレクトとして使用し。 codeクエリパラメータまたはリファラーヘッダー内。

注意すべき重要な点の 1 つは、これはログインやアカウント乗っ取りタイプの状況にのみ適用されるわけではないということで。
以下の設定ミスを確認し。

Slack との統合により、攻撃者が自分の Slack アカウントをすべての通知/メッセージの受信者として追加できるようになります。
Stripe の統合により、攻撃者が支払い情報を上書きし、被害者の顧客からの支払いを受け入れることが可能になります
PayPal の統合により、攻撃者が自分の PayPal アカウントを被害者のアカウントに追加できるようになり、攻撃者の PayPal に資金が入金されることになります。

メールアドレスに基づいたアカウントの割り当て

他によく見られる問題の 1 つは、アプリケーションが「X でサインイン」だけでなくユーザー名/パスワードも許可している場合で。
これを攻撃するには 2 つの異なる方法があります。

アプリケーションがアカウント作成時に電子メール認証を必要としない場合は、被害者が登録する前に、被害者の電子メールアドレスと攻撃者のパスワードを使用してアカウントを作成してみてください。その後、被害者が Google などのサードパーティに登録またはサインインしようとすると、アプリケーションが検索を実行して、電子メールがすでに登録されていることを確認し、被害者の Google アカウントを攻撃者が作成したアカウントにリンクする可能性があります。これは、被害者が登録する前に攻撃者が被害者のアカウントを作成した場合、攻撃者が被害者のアカウントにアクセスできる「事前アカウント乗っ取り」です。
OAuth アプリが電子メール検証を必要としない場合は、被害者の電子メールアドレスを使用してその OAuth アプリにサインアップしてみてください。上記と同じ問題が存在する可能性がありますが、逆方向から攻撃し、被害者のアカウントにアクセスしてアカウントを乗っ取ることになります。

秘密の開示

多くの OAuth パラメーターのうちどれが秘密であるかを認識し、それらを保護することが非常に重要です。たとえば、 client_idまったく問題なく必要ですが、漏れがあります client_secret危険です。これが漏洩すると、攻撃者は信頼できるクライアントアプリケーションの信頼性と ID を利用してユーザーを盗む可能性があります。 access_tokens統合されたアカウントの個人情報/アクセス。前の例に戻ると、私が見た問題の 1 つは、このステップをサーバーではなくクライアントから実行することです。

これがクライアントから行われた場合、 client_secret情報が漏洩し、ユーザーが生成できるようになります。 access_tokensアプリケーションを代表して。ソーシャルエンジニアリングを使用して、OAuth 認証にスコープを追加することもできます。リクエストは信頼できるクライアントアプリケーションから送信されるため、認証はすべて正当であるように見えます。

閉鎖

OAuth 実装では他にも多くの攻撃や問題が発生する可能性がありますが、これらはよく見られるものの一部で。
このような構成ミスは驚くほど一般的であり、これらの構成ミスから非常に大量のバグが発生し。
「クイック入門」はかなり短くするつもりでしたが、この投稿の残りの部分にはすべての知識が必要であることがすぐにわかり。
このことを考えると、ほとんどの開発者が安全に実装するための詳細をすべて知っているわけではないのも当然で。
多くの場合、これらの問題は個人データの漏洩/操作やアカウントの乗っ取りに関わるため、重大度が高くなって。
いつかこれらの各カテゴリについてさらに詳しく説明したいと思いますが、これは一般的な紹介として機能し、注意すべき点についてのアイデアを提供したいと考えて。

ほなほな。