この文書は2016年以降更新されていません
トランザクション認可に関するチートシート
|
最終改訂日 (yy/mm/dd): 2015/07/18
はじめに一部のアプリケーションでは、センシティブな操作を行っているのが認可されたユーザーであるかどうかを確認するために第 2 の要素を使用しています。一般的な例として、インターネットやモバイル向けのバンキングアプリケーションでよく使用される電信送金の認可が挙げられます。このプロセスを、ここでは"トランザクション認可" と呼ぶことにします。ただし、使用シナリオは金融システムだけに限ったものではありません。たとえば、ユーザーアカウントのロックを解除するためのある種のトークンが含まれたリンクや秘密のコードを記載した電子メールもトランザクション認可の特殊なケースです。ユーザーは、第 2 の要素 (自分の電子メールアドレス宛てに送られてきた一意のコード) を使用してアカウントのロック解除操作を認可します。 トランザクション認可は現在、さまざまな方法で行われています。一般的な例を次に示します。
これらの中には、物理デバイスまたはモバイルアプリケーションに実装できるものもあります。 マルウェア、フィッシング、パスワードやセッションのハイジャック、CSRF、XSS などによる攻撃の結果としての不正な電信送金を防ぐために、最新の金融システムにはトランザクション認可が導入されています。残念ながら、どんなコードでもそうですが、これらの保護対策も不適切な形で実装されることがあり、そのため迂回される可能性があります。このチートシートの目的は、トランザクション認可が迂回されないように適切にトランザクション認可を実装する方法についてのガイドラインを提供することです。 1.0 機能に関するガイドライン1.1 トランザクション認可方式は、重要なトランザクションデータをユーザーが確認できることが必要認可する対象が何であるかをユーザーが認識する必要があります。このため、認可方式は、当該トランザクションにおいて重要なデータをユーザーが確認できなければなりません。たとえば電信送金の場合は、送金先口座と金額です。 外部デバイスでトランザクションデータを確認できない方式 (生成された OTP だけを表示し、トランザクションデータを表示しない時間ベースの OTP トークンなど) は、ユーザーをマルウェア攻撃から防御しません。マルウェア攻撃を受ける可能性のあるアプリケーションでは使用しないでください。 どのトランザクションデータが重要であるかの判断は、実際のリスク、選択する認可方式の技術性能、およびユーザーエクスペリエンスの快適さに基づいて行います。たとえば、SMS メッセージを使用して重要なトランザクションデータを送信する場合、送金先口座、送金額および種別を送信できますが、非接続の CAP リーダーでユーザーがこれらのデータをすべて入力するのは不便です。このような場合は、最も重要なトランザクションデータ (たとえば、送金先口座番号の一部と金額) を入力するだけで十分でしょう。 1.2 認可資格情報の変更は、現在の認可資格情報を使用して認可するユーザーがアプリケーションインターフェイスを介して認可資格情報を変更できる場合は、その操作を、現在の認可資格情報を使用して認可する必要があります。たとえば、ユーザーが SMS コード用の電話番号を変更する場合には、現在の電話番号宛てに送信された SMS コードを使用して、この操作を認可します。 1.3 認可方式の変更は、現在の認可方式を使用して認可するアプリケーションによっては複数のトランザクション認可方式が用意されていて、ユーザーが現在使用している認可方式をアプリケーションインターフェイスから変更できます。このような場合、ユーザーは現在の認可方式を使用してこの変更を認可する必要があります。そうしないと、マルウェアによって、最も攻撃しやすい認可方式に変更されるおそれがあります。 1.4 ユーザー認証とトランザクション認可に別々の方式を採用するか、ユーザーがこの 2 つの操作を容易に区別できることが必要アプリケーションが本人認証と認可とでまったく同じ操作をユーザーに求めると、これをマルウェアが悪用し、ユーザーをだまして不正な操作を認可させる可能性があります。 次の例を見てみましょう。
上記の場合、ユーザー認証とトランザクション認可に同じ方式 (チャレンジ応答トークン) が使用されていました。マルウェアは、この点を悪用して、ユーザーに気付かれることなく、トランザクションの認可資格情報を引き出したのです。もちろん、採用された本人認証方式と操作認可方式にかかわらず、ソーシャルエンジニアリングによる攻撃が行われる可能性はありますが、アプリケーションではこのような攻撃シナリオを単純化してはいけません。 一般に、認可する対象の詳細がユーザーに明示されていれば、ユーザーをだまして無用なトランザクションを認可させることは、はるかに難しくなります。 1.5 各操作はそれぞれ一意な認可資格情報を使用して認可するアプリケーションによっては、操作の認可資格情報 (静的なパスワード、SMS 経由で送信されたコード、トークン応答など) を一度しか要求しません。この場合、ユーザーはそのセッション全体を通して任意のトランザクションを認可することになるか、操作の認可が必要になるたびに同じ資格情報を再利用することになります。このような動作は、マルウェア攻撃の防御には不十分です。マルウェアはこうした資格情報を盗聴し、それを使用して、ユーザーに気付かれることなく任意のトランザクションを認可するからです。 1.6 認可コンポーネントでは、認可される操作データを明示する操作を認可するとき、ユーザーは何に対する捜査を認可するのかを知る必要があります。マルウェアの脅威を考慮すると、ユーザーのコンピューターを信頼できるものと見なすことはできません。したがって、認可される操作データを、アプリケーションだけでなく認可コンポーネントにも明示してください。また、操作データを表示するかどうかの判断をユーザーに委ねてはいけません。たとえば、認可するトランザクションデータを表示するための追加手順 / 入力をユーザーに要求するのはお勧めできません (たとえば、モバイル認証アプリで、トランザクションの詳細を表示するためにキーを押すようユーザーに強制しないでください)。重要なトランザクションデータ (第 1.1 項を参照) は、トランザクション認可プロセスに不可欠な要素として必ず表示してください。また、重要トランザクションデータの確認を促すためのスムーズなユーザーエクスペリエンスを組み込むことが必要です。 トランザクション認可プロセスで外部デバイスへのトランザクションデータの入力をユーザーに求める場合は、(送金先口座番号などのように) このトランザクションに固有の値 の入力を促すプロンプトをユーザーに表示すべきです。プロンプトなしで値の入力だけを要求する方式は、第 1.4 項の例で説明したように、簡単にマルウェアに悪用されます。入力オーバーロード問題の詳細については、こちらの資料を参照してください。 2.0 機能以外に関するガイドライン2.1 認可はサーバー側で実行および強制する他のセキュリティ対策と同様、トランザクション認可はサーバー側で強制します。クライアントからサーバーへ送信される任意のデータを変更または削除することによって認可結果を変えたり、認可結果に影響を及ぼしたりできないようにする必要があります。たとえば、次のようなものです。
これを実現するには、次のような一般的なセキュリティプログラミングのベストプラクティスを実践します。
2.2 認可方式はサーバー側で強制する複数のトランザクション認可方式がユーザーに提供されている場合、サーバーは現在の (ユーザーがアプリケーション設定で選択した) 認可方式を強制する必要があります。クライアントから渡されたパラメーターによる操作では認可方式の変更ができないことが必要です。これが可能な場合、マルウェアが認可方式をより安全性の低い、あるいは最も安全性の低いものに変更するおそれがあります。 これが特に重要なのは、アプリケーションに、より安全な新しい認可方式を追加するときです。新しい認可方式が古いコードの上に構築されることは少なくありません。結果として、クライアントが古い方式向けのパラメーターを送信すると、ユーザーが既に新しい方式に切り替えたにもかかわらず、トランザクションが認可されることがあります。 2.3 トランザクション確認データはサーバー側で生成するトランザクション認可方式では、重要なトランザクションデータをプログラムを介して認可コンポートに渡す際に、これらのトランザクションデータの改変をクライアントに許さないよう特に注意してください。ユーザーが確認する重要なトランザクションデータはサーバー上で生成し、サーバー側に保持して、認可コンポートに渡すようにして、クライアントによる改ざんの可能性を完全に排除する必要があります。 よくあるアンチパターンは、重要なトランザクションデータをクライアント側で収集し、それをサーバーに渡す方法です。この場合、マルウェアがこれらのデータを操作できます。その結果、認可コンポーネントに渡すトランザクションデータを偽造できます。 2.4 アプリケーションで認可資格情報のブルートフォース攻撃を防止するトランザクションの認可資格情報をサーバーに送信して検証するとき、アプリケーションではブルートフォース攻撃を防護する必要があります。たとえば、サーバー側で定義された試行失敗の後にはトランザクション認可プロセスを再度やり直してください。または、その他のブルートフォース対策技術を採用する必要があります (「OWASP Authentication Cheat Sheet」を参照)。 2.5 どのトランザクション状態遷移を許可するかをアプリケーションで制御するトランザクションの認可は通常、複数のステップで実行されます。次に例を示します。
アプリケーションは、このようなビジネスロジックフローを順次処理し、順番どおりでない手順の処理や特に手順のスキップを防ぐ必要があります (OWASP ASVS 要件 15.8 を参照)。 これにより、次のような攻撃手法から保護できます。
2.6 トランザクションデータを入力後の改ざんから守るトランザクション認可プロセスでは、ユーザーによる初期入力後にトランザクションデータを改ざんする攻撃シナリオから保護する必要があります。たとえば、トランザクション認可プロセスの不適切な実装により、以下の攻撃を許してしまうことがあります (第 2.5 項で説明したトランザクション認可手順を参照)。
改ざんの防止の実装には、使用するプラットフォームに応じてさまざまな手法を取ることができますが、以下の項目を加味してください。
2.7 トランザクションの実行時にそのトランザクションが認可されたかどうかをシステムでチェックするトランザクション入力と第 2.5 項で説明した認可プロセスの結果として、トランザクションが実行されます。トランザクションを実行する直前に、そのトランザクションがユーザーによって適切に認可されたかどうかを検証する最終関門を設けてください。実行に連動したこの最終関門によって次のような攻撃を防ぎます。
2.8 認可データの有効期間を限定する一部のマルウェア攻撃シナリオでは、ユーザーの入力した認可データが C&C サーバーに送信されて、攻撃者の制御するマシンから利用されます。このプロセスは、多くの場合、攻撃者が手動で行います。このような攻撃を困難にするためには、トランザクションを認可する期間を、チャレンジまたは OTP の生成からトランザクション認可までの一定期間だけに限定する必要があります。また、こうした安全対策はリソース枯渇攻撃の防止にも有効です。通常のユーザーの行動を妨げないように、慎重に有効期間を選択してください。 2.9 認可データをすべての操作に対して一意にするあらゆる種類のリプレイ攻撃を防ぐためには、認可されたトランザクションデータがすべての操作に対して一意であることが必要です。これを実現するには、採用するトランザクション認可メカニズムによってさまざまな方法があります。たとえば、タイムスタンプ、通し番号、または乱数を、署名されたトランザクションデータ内かチャレンジの一部として使用します。
注意事項他にも、トランザクション認可の実装に際して考慮すべき点として以下が挙げられますが、これらはこのチートシートの範囲外です。
Authors and Primary EditorsWojciech Dworakowski, SecuRing @ ContributorsI would like to thank the following persons who helped by reviewing and providing valuable feedback to this work:
参考資料参考資料は次のとおりです。
Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
