| 脅威エージェント | 攻撃経路 | セキュリティ上の弱点 | 技術的な影響 | ビジネスへの影響 | |
|---|---|---|---|---|---|
| アプリ依存 | 攻撃難易度 容易 | 蔓延度 中 | 検出難易度 普通 | 影響度 重大 | アプリ / ビジネス依存 |
| 認証の脆弱性を悪用する脅威エージェントは、一般的に利用可能なまたはカスタムされたツールを使用して自動化された攻撃を実行します。 | 攻撃者が一旦、認証スキームに脆弱性があると知ってしまうと、モバイルアプリケーションのバックエンドサーバにサービスリクエストを送信することにより、認証を偽装したり回避したりします。そして、モバイルアプリケーションとの直接的なやり取りを回避します。この送信プロセスは、一般的にデバイス内のモバイルマルウェアや攻撃者が所有するボットネットを介して行われます。 | 認証スキームの不備もしくは欠如によって、モバイルアプリケーションで利用しているモバイルアプリケーション内やバックエンドサーバ内の機能を、攻撃者が匿名で実行することを許可することになります。モバイルデバイスの入力フォームが原因で、モバイルアプリの認証がより脆弱となることはよく見られます。なぜならこの入力フォームは、たいてい4桁のPINに基づいた短いパスワード使用を推奨しているからです。 モバイルアプリケーションの認証要件は、使いやすさを重視する観点から従来のWeb認証スキームとは全く異なります。 従来のWebアプリケーションでは、ユーザはオンラインかつバックエンドサーバとリアルタイムで認証することが期待されています。それらのセッションが継続する限り、ユーザのインターネットに対する持続的なアクセスについて合理的な期待があります。 モバイルアプリケーションでは、セッションが継続する間ユーザが常にオンラインであることは期待されていません。モバイルインターネット接続は、従来のWeb接続と比べてはるかに信頼性が低いためです。したがって、モバイルアプリケーションではオフラインでも認証を行うことが必要になる場合があります。このオフライン要件は、開発者がモバイル認証を実装する際の重大な考慮事項となります。 認証スキームの不備を検出するために、テスターはアプリケーションが「オフライン」モードのときに、モバイルアプリケーションに対してバイナリ攻撃を実行することが良いでしょう。攻撃を通じて、テスターはアプリケーションのオフライン認証を回避し、その認証が要求されるばずであった機能を実行することができます(バイナリ攻撃についての詳細はM10を参照)。 また同様に、テスターはモバイルアプリケーションに対するPOST/GETリクエストからセッショントークンを削除して、バックエンドサーバの機能を匿名で実行できるか試みるべきです。 |
認証不備の技術的な影響は、認証の結果をもって動的リクエストを実行しているユーザを識別できないことです。ユーザ識別することができないため、認証の結果をもってユーザアクティビティを記録し、また検査することが即座にできなくなる可能性があります。これにより、攻撃元や潜在的なリスク、または将来の攻撃を防ぐ方法を見つけ出すことができなくなります。 認証の不備は、潜在的な認可の不備をも明らかにするかもしれません。認証制御が機能しないとき、その認証結果をもってユーザの同一性を検証することができません。このユーザの同一性は、ユーザの役割やユーザに紐づく権限と関係しています。もし攻撃者が重要な機能を匿名で実行できたのなら、それはコードが、アクションを要求するリクエストを発行したユーザの権限を検証していないということを明確に意味します。したがって、匿名によるコードの実行は、認証と認可の制御両方における不備を浮き彫りにします。 |
認証不備のビジネスへの影響は、少なくとも以下の結果をもたらすでしょう。
|
|
モバイルアプリケーションには、以下のように安全でない認証の問題を抱える様々なケースがあります。
- アクセストークンを送信することなく、バックエンドAPIサービスのリクエストを匿名で実行することができるケース
- パスワードや共通秘密鍵をデバイスのローカルに保存しているケース
- パスワード入力を簡略化するために脆弱なパスワードポリシーを設定しているケース
- TouchIDのような機能を使用しているケース
次に示すような、「安全でないモバイルアプリケーションの認証」に関するアンチパターンを避けてください。
-
Webアプリケーションをモバイル版に移植する場合、モバイルアプリケーションの認証要件は、Webアプリケーションコンポーネントの認証要件と一致すべきです。したがって、Webブラウザよりも少ない認証要素で認証できるようにすべきではありません。
-
ユーザ認証をローカルで行うことは、クライアントサイドの認証回避につながります。アプリケーションがローカルにデータを保存している場合、ランタイム環境の操作やバイナリ改ざんによって、Jailbreakされたデバイス上で認証ルーチンが回避される可能性があります。もし、オフライン認証をせざる得ないビジネス要件がある場合には、モバイルアプリケーションに対するバイナリ攻撃を防ぐため、M10を参照してください。
-
可能であれば、全ての認証リクエストがサーバ側で実行されるようにするべきです。すなわち、認証成功時にアプリケーションデータがモバイルデバイスにロードされるようにするべきです。これにより、認証成功時にしか、アプリケーションデータが利用できなくなります。
-
クライアント側にデータを保存する必要がある場合、ユーザのログイン情報から安全に生成された暗号鍵を用いて、データを暗号化する必要があります。これにより、正しい認証情報が入力された場合にのみ、保存されているアプリケーションデータにアクセス可能となります。ただしこの場合であっても、バイナリ攻撃によってデータが解読されるというリスクが残ります。このようなローカルデータの窃取につながるバイナリ攻撃を防ぐには、M9を参照してください。
-
モバイルアプリケーションで実装される永続的な認証(Remember Me)機能は、デバイス内にユーザのパスワードを決して保存してはいけません。
-
理想的には、モバイルアプリケーションは、ユーザによってモバイルアプリケーションから消去可能なデバイス固有の認証トークンを利用すべきです。これにより、アプリケーションが盗難されたもしくは紛失したデバイスからの不正アクセスを軽減することができます。
-
ユーザを認証するために、改ざん可能な値は使用しないでください。これには、デバイス識別子や位置情報が含まれます。
-
モバイルアプリケーションにおける永続的な認証は、オプトインとして実装すべきであり、デフォルトでは有効にすべきではありません。
-
可能であれば、ユーザが4桁のPINコードを認証パスワードとして使用することを許可しないでください。
- 開発者は、全てのクライアント側の認可及び認証の制御が悪意のあるユーザによって回避される可能性があることを想定するべきです。できる限りサーバ側で、認可及び認証の制御を再実施すべきです。
- オフラインでの認証が求められる場合、モバイルアプリケーションは、そのコード内でローカル認証または認可のチェックを行なうことになるでしょう。このような場合に、開発者は不正なコード改ざんが行われていないか検証するため、コード内でローカルの整合性チェックを実施する必要があります。バイナリ攻撃に対する検知と対応に関する情報はM9を参照してください。
以下、モバイルアプリケーションにおける脆弱な認証及び認可の制御がなされているケースを示します。
シナリオ #1： 隠されたサービスリクエスト
開発者は、モバイルアプリケーションがバックエンドに送信するサービスリクエストは、認証されたユーザだけが生成できると思い込んでいます。リクエスト処理時に、サーバ側のコードは受け取ったリクエストが既知のユーザと関連しているかどうかを検証しません。それゆえ、攻撃者はバックエンドサービスにサービスリクエストを送信し、処理結果の対象となる正規ユーザに影響を与える機能を匿名で実行することができます。
シナリオ #2： インターフェース依存
開発者は、認証されたユーザだけがモバイルアプリケーション上の特定の機能を表示できると思い込んでいます。それゆえ、認証された正規のユーザのみがモバイルデバイスからそのサービスに対してリクエストを発行することができると考えます。リクエストを処理するバックエンドのコードは、そのリクエストに関連するIDがサービスを実行する許可を与えられているかどうか、わざわざ検証しません。それゆえ、攻撃者はかなり低い権限のユーザアカウントで、リモート管理機能を実行することができます。
シナリオ #3： ユーザビリティ要件
ユーザの利便性を考慮した結果、モバイルアプリケーションは4桁のパスワードの使用を許可します。そのパスワードを、サーバのコードはハッシュ化して保存します。しかしながら、ひどく短いパスワードのため、攻撃者はレインボーハッシュテーブルを用いてオリジナルのパスワードを素早く推測することが可能です。もし、サーバ上のパスワードファイル(もしくはデータストア)が漏えいすれば、攻撃者はユーザのパスワードを素早く推測できるでしょう。