モバイルアプリケーションの時代のOAuthセキュリティ、またはインターネットが沈黙していること

「VKontakte APIはOAuth 2.0オープンプロトコルを使用してアクセスキーを取得します。 同時に、ユーザーはアプリケーションにログインとパスワードを転送しないため、アカウントが危険にさらされることはありません」 -VK APIドキュメント



「OAuthは、モバイル、デスクトップ、およびWebアプリケーションにシンプルで安全な認証方法を提供するオープンプロトコルです」 -スローガンoauth.netの無料翻訳。



残念ながら、多くの場合、これらのステートメントは間違っています。 エンドユーザーの観点から、および独自のOAuthプロバイダーを実装する際の両方で、OAuthを使用して安全に作業する方法をお読みください-猫の下で読んでください。 これらのセキュリティの側面が考慮されますが、現在、公開されている出版物ではあまり注目されていません。



材料は特定の用語で飽和しており、訓練を受けた読者向けに設計されています。

著者から

著者は情報セキュリティの分野の専門家ではなく、100％正しいと主張していません。 エッセイは、確立されたパラダイムで戦争の炎を再燃させる試みではなく、使用される技術とその適用可能性の分野に対する健全な好奇心と批判的な態度を読者に喚起する可能性が高い。 以下のすべては、パブリックAPIへのアクセスを制御するための他の同様のプロトコルおよびメソッドについて、多少なりとも当てはまります。

歴史的背景

私たちは技術の急速な発展の時代に生きています。 新しいものを自由に利用できるようになり、積極的にそれを活用し、適用性の限界を押し広げ、ますます複雑で多様な問題を解決します。多くの場合、シリーズの認知的方法によって導かれます。「それは問題なく、大丈夫です」これも役立ちます。」「多くの人が使用しているので、それは良いことです。」 このアプローチは自然です。ほとんどの状況で機能し、特に少数の人々が作業の結果を使用する場合、およびエラーのコストが低い場合、時間と労力をあまり費やすことなく結果を得ることができるためです。 私の意見では、このように使用境界がプッシュされたテクノロジーの1つはOAuthです。



まず、少し歴史があります。Wikipediaによると、プロトコルの作業は2006年11月に始まり、OAuthバージョン1.0は2007年12月4日に承認されました。 それは、FirefoxがWeb開発者やインターネットオタクのコンピューターだけでなく、一般の人々のマシンでもInternet Explorerを徹底的にプッシュし始めたときでした。 Facebookはすべてのインターネットユーザーが利用できるようになり、VKontakteが登場し、Gmailは招待なしで登録を開始しました。 モバイルインターネットは遅く、スマートフォンはまれでした。 したがって、OAuth標準の開発者は、ブラウザが安全で信頼でき、ユーザーがインターネットリソースにアクセスする唯一の方法であると自然に信じていました。 委任状とブラウザのセキュリティに対する責任は、ユーザー（PCに更新プログラムをインストールし、ウイルスがないことを監視する必要性の形式）および開発者（これらの同じ更新プログラムを提供する必要性の形式）に帰属します。 そのようなシステムは関連性があり、次の技術の飛躍が起こるまで非常によく機能しました。2007年6月に最初のiPhoneが発売され、2008年9月にAndroid OSの最初のバージョンがリリースされました。

ユーザーセキュリティ

モバイルプラットフォームの市場（または、どこにでもあるディストリビューション）に参入することで、ブラウザーの委任状の委任状が無関係になるのはなぜですか？



モバイルプラットフォームの開発者は、TCP / IPスタックへの無料アクセスなど、アプリケーションを作成するための十分な機会をプログラマに提供しました。 その結果、ユーザーはユーザー名とパスワードを実際に入力した場所を確認できなくなり、適切なWebサイトからこのWebフォームが本当に開いているかどうかを確認する方法がありません（たとえば、WebViewを使用している場合）悪意のあるアプリケーション開発者によるキーストロークまたは入力データ。 さらに、モバイルプラットフォームの開発者は、しぶしぶ埋め込みブラウザ用のAPIを拡張しているため、この状況を悪化させているだけです。



パスワード入力フォームが本物のように見えても、ユーザーはもっと注意する必要があり、市場からインストールした最初のカウンターアプリケーションにソーシャルネットワークのユーザー名とパスワードを入力しないでください。 一般に、パスワードの入力を求められた場合、正直なアプリケーションはおそらく対応するソーシャルネットワークの認証SDKを使用するため、これは何かが間違っていることの明確な兆候です。 しかし実際には、ユーザーはブラウザーの「VKontakte経由でログイン」および「Facebookでログイン」ボタンに慣れているため、同じボタンを使用してアプリケーションにログインとパスワードを入力するための対応するフォームが表示されても混乱しません。 かなり前に一度変更され、1、2回入力されたパスワードを痛々しいほど思い出すでしょう。 このように、ブラウザを介して使用されたとしてもOAuthにとって非常に深刻なフィッシングの問題は、まったく新しいレベルにまで上昇します。



OAuth開発者はこれを何と言っていますか？ 2012年10月にリリースされたOAuth 2.0には、モバイルアプリケーションに関する言葉はありません。 2016年2月にのみ登場したネイティブアプリ向けOAuth 2.0というドキュメントの暫定版では、アプリケーション開発者とOAuthプロバイダーは、ユーザーが頻繁にパスワードを入力したり、ユーザーがログインしたアカウントに関連する情報を表示したりしないようにすることをお勧めします。 したがって、ユーザーは悪意のあるアプリケーションの場合に何かがおかしいと疑うことができます。



一方、いずれかの形式のすべての主要なOAuthプロバイダーは、モバイルアプリケーション用のSDKを提供します。これにより、OAuthではなくプロバイダーのアプリケーションを介してユーザーを承認できます。 一見、すべては問題ありませんが、ユーザーがプロバイダーのアプリケーションで承認されていない場合は、ユーザー名とパスワードを入力することをお勧めします。プロバイダーのアプリケーションがインストールされていない場合、SDKはほとんどの場合、既におなじみのOAuthの承認を開始します。フィッシングの新しい活動分野。



これらの問題にもかかわらず、インターネットサービスの知識のあるユーザーは、単純なルールに従えばそれほど悪くはありません：プロバイダーのOAuth Webサイトまたはアプリケーションでのみパスワードを入力し、ユーザーは自動的にアクセスするのではなく、自分でアクセスする場合のみです。 はい。更新、インストールされているソフトウェアの制御、場合によってはウイルス対策に加えて、これらすべてが可能です。

OAuthプロバイダーの問題

私たち自身がOAuthプロバイダーになりたい（またはすでに）場合、すべてがより興味深いものになります。 承認コードフローを実装し、APIが制御されたサービスにのみ使用されているとしましょう-これまでのところ、すべてがうまくいくようです。 次に、外部サービスにアクセスする必要がありました。「もちろん、OAuthはこのために設計されていますよね？」-私たちは考えています。 しかし、ここで考えが忍び込んでいます：どの特定の外部サービスを使用するのでしょうか？ これらのサービスが実際にモバイルアプリケーションになる場合はどうなりますか？ それでは、アプリケーションはどのようにしてclient_idとclient_secretのセキュリティを保証できますか？ それでは、悪意のあるアプリケーションが完全に無害なふりをして、そのためにあらゆる種類の不名誉を行っているかどうかをどのようにして見つけることができますか？



残念ながら、OAuth2はこの質問に対する回答を提供していません。RFC6749の10.1節のみが、モバイルまたはクライアントアプリケーションとして実装されたOAuthクライアントを認証するためにパスワード（client_secretについて話している）を使用することは禁止（!!!）このパスワード（および一意のclient_id）が、ユーザーデバイス上の特定のアプリケーションインストールごとに個別に発行される場合（ただし、このような場合にはほとんど関心がありません）。 2017年3月2日付のバージョン（ 段落8.8、8.9 ）から始まる「モバイルクライアント向けOAuth」のドラフトは、アプリが主張するHTTPS URIリダイレクトの使用を提案していますが、このアプローチの安全なバージョンがiOS 8、Android 6.0のみで利用できることを意味するものではありませんとアップ 。 このアプローチはユーザーを悪意のあるアプリケーションから保護しますが、OAuthプロバイダーが他のclient_idを引き継いだ悪意のあるクライアントを検出するのに役立ちません。 同時に、この標準では、プロバイダーの実装がモバイルアプリケーションとサーバーアプリケーションをどのように区別するかについての推奨事項を提供していません。 つまり 実際、client_secretセキュリティは完全にクライアントの手にありますが、これは私たちの制御が及ばない可能性があります。



まあ、標準は私たちのアシスタントではないので、私たちは私たち自身の常識を使用します。 サーバーアプリケーションのみを実行する必要があるとします-すべてが比較的単純です。各client_idに、トークンの要求を送信できるIPアドレス（または複数）をバインドする必要があります。 このリストを作成するユーザーインターフェイスを提供することもできます。主なことは、これらのアドレスが多すぎないように制御することです。 そして、誰かがホスティングプロバイダーのサブネット全体を紹介し、すべてのセキュリティに別れを許します。攻撃者が1つのデータセンターのクライアントで解決すれば十分です。



さて、モバイルアプリケーションへのアクセスを提供する必要がある場合はどうでしょうか。 当社のサービスの使用が特定の料金を意味し、アプリケーションが当社の管理下にある場合、購入後にAppStoreとPlayマーケットが提供するアカウントメカニズムを使用できます。 これらのアカウントにはアプリケーションのバンドルIDが含まれ、特定のユーザーに関連付けられており、リクエストをAppleまたはGoogleに送信することでサーバー側で確認できます。 アカウントの検証は、たとえば、アクセストークンまたは更新トークンの更新に関連付けることができます。



サービスが無料の場合、この方法は機能しない可能性があります。「無料」で購入できるにもかかわらず、アプリケーションユーザーは銀行カードの詳細を入力する必要があります。 また、モバイルアプリケーションが私たちのものでない場合、この方法は機能しません。プラットフォーム開発者は、サードパーティアプリケーションで購入を制御するメカニズムを提供しません。



アプリケーションのユーザーサークル（企業の従業員など）がよく知られ、制御されている場合、クライアント証明書を使用してクライアントを承認できます。 一方、ユーザー証明書が企業で積極的に使用されている場合、APIへのアクセス制御は、独自のOAuth拡張を実装するよりも、TLSに基づいて実装する方がおそらく便利です。



それでも、アプリケーションのユーザーサークルが十分に広く、ユーザーに購入を促し、カードの詳細を入力させたくない場合はどうでしょうか。 少し前までは、アプリケーションでclient_id（client_secret）を難読化することと、OSネットワークスタックで暗号化されていないトラフィックを傍受することの難しさだけがありました。 このようなタスクの堅牢な実装には、高度な専門家トレーニングと多くの時間が必要です。 したがって、中小企業やフリーランスのプログラマーには実質的にアクセスできません。



幸いにも、Googleはある時点からSafetyNetサービスを提供します。これにより、アプリケーションが署名されたキーのフィンガープリントとバンドルIDを検索し、サーバー側でこのデータを確認できます（サービスの機能を確認するときに、別の回答を取得することはできませんでした{「isValidSignature」：false}）。 このAPIはGoogle Play Servicesの一部として提供され、理論的にはAndroid 2.3以降でPlayサービスが更新されていれば利用可能です。



SafetyNetが他の開発者によって公開されたアプリケーションのデータのチェックを許可するかどうかという問題は未解決のままです。したがって、それを使用して他のアプリケーションからAPIへのアクセスを制御できますか？ ドキュメントはこの質問に対する明確な答えを与えませんが、そのようなシナリオを暗示しないキーで書かれています。 また、Google Play Servicesはすべての国で利用できるわけではなく、中国のメーカーの電話では利用できない場合があります。



残念ながら、現時点ではAppleは同様のサービスを提供していません。 しかし、いずれにせよ、これは大きな前進であり、場合によっては、SafetyNetを使用することは、クライアントデバイス用の他の認証メカニズムよりも便利かもしれません。



提案されたオプションがどれも私たちに合わない場合はどうしますか？ 次に、パブリックAPIの開発者として、クライアントアプリケーションを確実に区別することはできず、ユーザーはどのAPIリソースをどのアプリケーションに提供するかを実際に制御できないことに注意する必要があります。 つまり、OAuthのスコープとclient_idの概念に依存することはできません。これは、プロトコルが提供する機能の約半分です。 または、十分な能力とリソースがあれば、サーバー側にヒューリスティックアルゴリズムを実装して、偽のclient_idを使用してリクエストを判断できます。



主要なOAuthプロバイダーが最後の2つ（残りはあまりにも厳しい制限を課している）の1つを使用し、OAuthを回避するためにここで提案されているメソッドを使用することを望みます。 間接的に、これは、たとえば、VKontakteが特定の信頼できるアプリケーションにのみユーザーのメールへのアクセスを許可する前に、そのような要求がパブリックAPIに含まれるという事実によって示すことができます 。

合計

上記のすべてから、OAuthは実際には、TLSやSSHなどの産業技術の使用を暗示するために使用されるセキュリティのレベルから非常に遠いものであると結論付けることができます。 OAuthプロバイダーを実装する場合、その実装の利点と潜在的なすべてのセキュリティ問題を慎重に検討する必要があります。 また、一般的なWebフレームワークの作成者に知られているライブラリはどれも考慮に入れていないため、上記の問題に対して適切な回避策を実装する必要があります。 モバイルアプリケーションからAPIにアクセスするには、ユーザーのOAuthとやり取りするための最も安全な方法を使用して独自のSDKを開発することが理にかなっている場合があります。



著者は、この資料を準備するための建設的なコメントと支援に友人や同僚に感謝します。また、Apple iOS SDKの機能の調査に協力してくれたSergey Mackenuに感謝します。



OAuthロゴはChris Messinaによって設計され、 Creative Commons Attribution ShareAlike 3.0ライセンスの下で配布されています。



UPD 05/11/2017 ：明らかに、OAuthには別のフィッシング攻撃ベクトルがありますが、これを防ぐことは非常に困難です。RIAインターフェースに認証ページを導入します。 これは、GMailユーザーに対する最近の攻撃の成功によって証明される可能性があります 。



UPD 05/13/2017 ：Googleは、 WebViewを介してOAuth認証ページのオープンをブロックすることにより、OAuthフィッシングとの闘いを続けています。 私の意見では、UserAgentヘッダーは依然として攻撃者によって書き換えられる可能性があるため、これは半分の対策に過ぎません。 ブラウザの他の際立った機能をシミュレートすることもできます。