認証とアクセス制御でアプリケーションのセキュリティを確保する
学習の目的
この単元を完了すると、次のことができるようになります。
- 認証とアクセス制御を実行することの重要性を説明する。
- 認証の不備を利用した攻撃手法を説明する。
- アクセス制御の不備を利用した攻撃手法を列挙する。
アプリケーションの認証とアクセス
空港のセキュリティを想像してください。搭乗前に、乗客は身分証明書を発券係に提示する必要があります。発券係は身分証明書を乗客名簿と照合し、悪意のある人物のデータベースに照らして精査します。このような物理的な認証ステップは、ユーザーがアプリケーションなどの技術的リソースにアクセスする前に完了しなければならない論理的な認証ステップとよく似ています。
アプリケーションセキュリティエンジニアは、データアクセスを識別、認証、承認されたユーザーに制限します。認証では、ログイン情報 (通常はユーザー名とパスワード) を使用してアプリケーションにログインすることで、ユーザーの ID が確認されます。これにより、アプリケーションでユーザーに必要な権限を付与するこが可能になり、ユーザーは機能によってはアクセスが制限されたり、許可されたりします。リソースへのアクセスを付与および制限するこの概念は、承認と呼ばれます。ユーザーを識別、認証、承認するプロセス全体はアクセス制御と呼ばれます。
アプリケーションセキュリティエンジニアは、アプリケーションの承認、ログイン、ユーザー権限を管理する上で重要な役割を果たします。そうすることで、攻撃者にパスワード、鍵、またはトークンが侵害されることを防ぎます。そのために、アプリケーションエンジニアは、アプリケーションへのアクセス、特に特権 (管理者) アクセスを制御、管理、監査します。
エンジニアは、可能な限り少ない権限 (最小権限として知られる概念) を使用してアプリケーションを実行します。また、垂直的および水平的なアクセス制御の問題がないか、アプリケーションをテストします。水平的な問題は、あるユーザーが別のユーザーの情報を表示/変更できる場合に発生します。垂直的な問題は、ユーザーが不適切に管理者アクセス権を取得できる場合に発生します。
たとえば、アプリケーションセキュリティエンジニアは、攻撃者が承認をスキップしてシステム内のリソースに直接アクセスできる、安全でない直接オブジェクト参照から保護します。これは、アプリケーションで、ユーザーが行った入力が受信され、十分な承認確認が実行されることなく、その入力を使用してオブジェクト (データベースのレコードやファイルなど) が取得される場合に発生します。
通常、トークンは次のように使用されます: リソースごとに認証する代わりに、ユーザーは認証を一度行い (一定期間のセッション内)、サーバーから期間限定のトークンを取得し、そのトークンの ID データをセッション中の以降の認証に使用します。
認証の不備から保護する
アプリケーションセキュリティエンジニアが防御するリスクの 1 つは、「認証の不備」と呼ばれています。これは、攻撃者がアカウントに不正にアクセスし、システムを侵害する場合に発生します。このリスクの影響は深刻で、たとえば、攻撃者がマネーロンダリングを行ったり、他人の社会保障給付金を盗んだり、さらにはその人の ID を盗んだりすることさえできます。攻撃者が認証の不備を悪用するリスクは高いのです。
攻撃者は、他人のソーシャルメディアでのプレゼンスから情報を推測したり、ダークウェブで販売されている有効なログイン情報を使用したりすることで、有効なユーザー名とパスワードに簡単にアクセスできます (クレデンシャルスタッフィングと呼ばれる手法)。攻撃者は、アプリケーションや関連付けられたソフトウェアがデフォルトの管理者アカウントを使用しているかどうかをテストします。うまくいかない場合は、攻撃者はブルートフォース攻撃を使用してユーザーパスワードを推測するか、辞書の各単語をパスワードとして体系的に入力する自動プログラム (辞書攻撃と呼ばれる) を使用して不正にアクセスします。
クレデンシャルスタッフィングとは、攻撃者がある企業の大規模なデータ侵害からユーザー名とパスワードを取得し、そのログイン情報を使用して他のデジタルサービスにログインすることです。多くの人がサイト間でユーザー名とパスワードを再利用しているため、攻撃者は最初に侵害されたアカウント以外の他のアカウントにもアクセスできます。
本当に恐ろしいですよね。アプリケーションセキュリティエンジニアはどのように貢献できるでしょうか? アプリケーションを評価し、認証の不備に対して脆弱でないことを確認するという重要な役割を担っているため、アプリケーションセキュリティエンジニアは、次の弱点について確認します。
デフォルト、弱い、またはよく知られているパスワード
エンジニアは、アプリケーションでデフォルトのログイン情報 (管理者アカウントの admin/admin など) が使用されていないことを確認します。また、アプリケーションに弱いパスワードがないかを確認して、ユーザーに一定の文字数や特殊文字を含むパスワードの作成を要求し、共通のパスワードを許可しません。米国標準技術局 (NIST)は、パスワードの長さ、複雑さ、ローテーションに関するガイドラインを設けています。
知識ベース認証 (KBA)
多くの場合、Web サイトでは、ユーザーは自分が育った通りの名前や愛犬の名前など、KBA の質問を使用してパスワードをリセットできます。このアプローチの問題点は、このような個人情報の多くがその人のソーシャルメディアでのプレゼンスやダークウェブでの以前の侵害で流出した情報から取得される可能性があることです。
アプリケーションセキュリティエンジニアは、KBA よりも強力なアカウント回復メカニズムを実装します。たとえば、ユーザーがアクセス可能な登録済みのメールや電話番号へのコード送信を必須にするなどです。また、ログインの失敗回数を制限して遅延させることで、攻撃者がブルートフォース攻撃や辞書攻撃を使用してパスワードを推測するのを防ぎ、失敗したログインについてアプリケーションからシステム管理者にアラートで通知されるようにします。
プレーンテキストまたは弱くハッシュ化されたパスワード
ユーザーにパスワードをプレーンテキストに入力させて保存すると、悪意のある攻撃者が簡単にパスワードを判別できてしまいます。アプリケーションセキュリティエンジニアは、アプリケーションリソースのすべてのパスワードが必ずソルト付きでハッシュ化されるようにします。これは、料理本のレシピのように聞こえるかもしれませんが、つまり、パスワードにさらにデータが追加され、復号できない方法でスクランブルされるということです。
こうすることで、たとえ誰かがパスワードを盗んだとしても、それを使用することはできません。パスワードのハッシュ化に使用されるコンピューターアルゴリズム (MD5 など) の中には、すぐにリバースエンジニアリングできてしまう弱いアルゴリズムもあります。アプリケーションセキュリティエンジニアは、このようなアルゴリズムの使用を避け、代わりに強力なハッシュアルゴリズムを実装します。
単要素認証
ユーザー名とパスワード (ユーザーが知っている情報) のみを使用することは、単要素認証 (SFA) と呼ばれます。攻撃者は、パスワードを推測したり、盗んだりできるため、アプリケーションセキュリティエンジニアは、アプリケーション認証を保護するために、可能な限り多要素認証 (MFA) を実装します。
MFA では、ユーザーが知っているもの (パスワードなど) とユーザーが持っているもの (携帯電話など) の両方、またはユーザーに固有のもの (顔や指紋など) が使用されます。たとえば、ユーザーがアプリケーションでユーザー名とパスワードを入力すると、別の認証要求が携帯電話に送信され、ユーザーはこの要求も承認する必要があります。このようにセキュリティレイヤーを追加することで、攻撃者がアカウントを侵害しにくくなります。
セッション ID とトークンの不適切な管理
セッション ID とトークンの管理が適切に行われていない場合、攻撃者はセッションを乗っ取り、被害者になりすますことができます。セッション ID を乗っ取りから守るために、エンジニアはいくつかの対策を実施します。ID の名前をわかりにくくして、アプリケーションで使用されているテクノロジーやプログラミング言語に関する情報を攻撃者が取得できないようにします。
パスワードと同じように、セッションID もブルートフォース攻撃を防ぐのに十分な長さにする必要があります。また、攻撃者に推測されないように予測不可能にすることも必要です。さらに、アプリケーションセキュリティエンジニアはセッション ID の意味やビジネスロジックをサーバー側 (ユーザーが利用可能なクライアント側ではない) に保存します。
最後に、アプリケーションセキュリティエンジニアは、ゼロから新しいツールを作成するのではなく、組み込みのセッション管理ツールを実装し、使用することにしたフレームワークの脆弱性を認識します。セッション管理に関する詳細は、関連する「OWASP Cheat Sheet (OWASP 早見表)」を参照してください。
セッションは、アプリケーションに送信され、ユーザーに関連付けられた一連の要求と応答です。セッション中は、セッション ID によってユーザー操作に対するアクセス権が確立されます。
アクセス制御の不備から保護する
認証はユーザーをアカウントにログインさせるプロセスであるのに対し、アクセス制御はユーザーの権限ポリシーを適用するプロセスです。不備があると、攻撃者は他人のアカウントを参照または編集する方法を見つけたり、権限機能を使用してシステム管理者として行動し、レコードにアクセスして変更または削除を行ったりします。これは一般的なセキュリティの弱点であり、攻撃者がアクセスできるデータの種類によっては深刻な影響が及ぶ可能性があります。
アプリケーションセキュリティエンジニアは、複数の手法を使用して、このリスクからアプリケーションを保護します。
- デフォルトで拒否する: 特別に許可されていない場合、要求は拒否されます。たとえば、システム管理者が新しいユーザーアカウントを作成すると、そのアカウントは設定されるまで、デフォルトでアクセス権を最小限またはアクセス権なしにする必要があります。
- 最小権限: すべてのユーザーに付与されるアクセス権を可能な限り少なくします。
- レコードの所有権を適用する: 特定のユーザーのみがレコードの作成、参照、更新、削除を行います。
- アクセス制御の失敗をログに記録する: 誤ったパスワードが入力された場合にレコードを作成し、システム管理者にアラートを送信します。
- トークン管理: トークンの有効期限を設定し、保存されているトークンをログアウト時に削除します。これにより、トークンが無期限に使用されることを防ぎ、攻撃者がトークンを改ざんして権限を昇格できないようにします。
- 早期に頻繁にテストする: 最後に、アプリケーションセキュリティエンジニアは、品質保証プロセスと SDLC 全体にわたって、上記のアクセス制御の保護をテストします。
まとめ
アプリケーションセキュリティエンジニアがアプリケーションの認証とアクセス制御機能を保護し、正当なユーザーのみが割り当てられたリソースと機能にアクセスできるようにするための手法を説明しました。次は、アプリケーションの保護に関する最後の考慮事項、つまり機密データが漏洩しないようにすることについて詳しく説明します。