ウェブアプリケーションは、しばしば悪意のある攻撃者に狙われます。これらのアプリケーションは一般にアクセス可能であり、少なくともそのログインページは一般にアクセス可能です。攻撃者はしばしば、ウェブ・アプリケーションのログイン・ページのセキュリティの脆弱性を悪用し、過度な負荷 を引き起こし、サイトをダウンさせようとします。
そのような脆弱性の1つは、多くのログインフローの一部であるセキュリティ質問ページに見られます。この投稿では、このシナリオを見て、なぜそれが問題なのかを検討し、セキュリティリスクを軽減する方法についてガイダンスを提供します。
空白のセキュリティ質問があるログインページ
ログインページのセキュリティ脆弱性は、あなたが思っている以上に一般的です。多くのウェブサイトやアプリケーションのログイン・プロセスでは、セキュリティを高めるために、従来のユーザ名/パスワードのステップをさらに検証のためのセーフガードで拡張しています。2段階のログインフローを想像してください。最初のステップでは、サイトがユーザー名とパスワードの組み合わせを尋ねます。これらの認証情報を正しく入力すると、2つ目のステップでセキュリティの質問（最初にアカウントを設定したときに指定したもの）に答えるよう求められます。
この2つ目のステップは、通常、最初のステップを成功裏に完了したユーザーに基づいてセキュリティ質問を挿入するページビューテンプレートから構築されます。2ステップログインフロー全体は基本的にこのように動作します：
- アリスはhttps://www.example.com/login、ログインページにアクセスする。
- アリスはユーザー名とパスワードの組み合わせを送信する。
- サーバーは送信されたクレデンシャルを検証する。
- 認証情報が正しいので、サーバはブラウザをhttps://www.example.com/login2、フォローアップページにリダイレクトする。リクエストヘッダには、アリスがログインフローの最初のステップを通過したことを確認するための一意なトークンが含まれる。
- サーバーはこのページをテンプレートに基づいてレンダリングし、アリスのために取得されたセキュリティ質問を、応答のためのテキスト入力と送信ボタンと一緒に挿入します。
- アリスはセキュリティの質問に対する回答を提出する。
- サーバーはアリスがセキュリティ質問に正しく答えたことを確認し、ログインする。
フローの2ページ目、https://www.example.com/login2。最初のステップを経ずに、ブラウザで直接そのページにアクセスしたらどうなるか、想像してみてください。
あるシナリオでは、サーバーがリクエストヘッダに有効なトークンがないかどうかをチェックし（つまり、ログインフローの最初のステップをうまく通過できなかった）、単純にhttps://www.example.com/login にリダイレクトしてやり直させる可能性がある。
しかしながら、別の可能性のあるシナリオでは、サーバはテンプレートに基づいてページをレンダリングします。ユーザーに対応するセキュリティの質問を見つけることができず（どの中途半端に認証されたユーザーであるかをサーバーに伝えるトークンがないため）、結果のページは次のようになる可能性があります：
あなたは、セキュリティ上の質問がない...厄介なセキュリティ上の質問ページが残っている。無意味なページについて話そう。
確かに無意味だ。でも無害？そうとも言い切れない。
安全保障への影響
このシナリオを続けて、あなた（またはあなたより悪意のある人）がこの「セキュリティの質問」に対する答えを提出したらどうなるでしょうか？サーバーはあなたの答えを評価するためにCPUサイクルを使う。サーバーはテキスト入力を処理し、リクエストヘッダ中のユニークトークンを探し、そしておそらくあなたの答えを検証するためにデータベースクエリを実行します。
空白のセキュリティー質問があるログイン・ページは些細なことに思えるかもしれないが（CPUサイクルがあちこちで浪費されて何が悪い）、重大なセキュリティー問題につながる可能性がある。
- バックエンドの処理リソースの浪費：無意味なフォーム送信の処理は、ネットワークとコンピューティングリソースを消費します。
- サービス拒否（DoS）攻撃の可能性：攻撃者がボットネットを立ち上げ、フォーム送信を繰り返し、システムに過負荷をかける可能性がある。
- 脆弱性の増大：DoS攻撃が成功すると、システム全体がダウンする可能性がある。
攻撃者がこの弱点を悪用してサーバーの処理能力を浪費することができれば、正規ユーザーのサービスを妨害し、システムをさらなる攻撃にさらす可能性がある。
結局のところ、それほど無害ではない。
アプリケーションのセキュリティと信頼性を維持するために、このような脆弱性に対処する方法を見ていきましょう。
どう守るか
この具体的なシナリオでは、login2エンドポイントを処理するサーバーは、リクエストヘッダに有効なトークンが存在することを確認する必要がある。適切なトークンがなければ、それ以上の処理は行われず、ユーザはログインフローの最初のステップにリダイレクトされます。こうすることで、404や401の場合のように、リクエストを優雅に処理するために使われるリソースを最小限に抑えることができます。
しかし、このシナリオは、より一般的なセキュリティ上の懸念を浮き彫りにしています。確かに、空白のセキュリティ質問を含む無意味なログインページを悪用すると、処理リソースを大量に使用するため、より迅速にサーバーに負荷をかけることができます。しかし、ボットネットは、完全に正常なユーザー名/パスワードのログインページにも過剰なリクエストを送る可能性があります。
このような攻撃からウェブ・アプリケーションを守るには、以下の対策を実施してください：
- ウェブアプリケーションファイアウォール（WAF）を使用する：WAFは、DoS防御を提供し、悪意のあるボットを検出してブロックし、自動化された攻撃のリスクを減らすことができます。LinodeのアプリのマーケットプレイスにはHaltdos Community WAFがあり、これを利用することができます。
- レート制限を導入する：1つのIPアドレスが一定時間内に何回リクエストできるかを制限する。レート制限を導入することで、攻撃者（およびボット）によるリクエストの殺到を防ぐことができます。
- モニタリングとアラートの有効化継続的な監視ツールは、疑わしいリクエストパターンを監視し、潜在的な攻撃をリアルタイムで警告します。即座に通知されれば、迅速に対応し、問題を軽減することができます。
結論
空白のセキュリティ質問があるログインページのケースを見てきました。一見すると、最終的には無意味な奇妙なエッジケースのページに見えます。しかし、攻撃者はこのような脆弱性を悪用してリソースを浪費し、システムをダウンさせる可能性があります。セキュリティの質問ページは、そのような脆弱性の一例に過ぎません。
セキュリティを念頭にアプリケーションを設計し、セキュアなコーディング手法を採用しているのであれば、幸先 の良いスタートを切ることができるでしょう。しかし、アプリケーションには、WAF、レート制限、継続的な監視、アラートの使用など、システムやインフラ のレベルで実装されたセキュリティ対策も必要です。適切なセキュリティ対策を講じることで、このような攻撃に狙われるリスクを大幅に減らすことができます。
アプリケーションのセキュリティに関するより多くのガイダンスやヒントについては、Linodeのドキュメントをご覧ください。そこには、あなたのシステムとユーザーを保護する方法を指示するための有用なリソースがあります。
コメント