Coders Conquer Security:シェア＆ラーンシリーズ - 認証
このブログでは、ウェブサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する最も一般的な問題の1つを取り上げます。このブログでは、Webサイトを運営している企業や、従業員がリモートでコンピュータリソースにアクセスする際に直面する最も一般的な問題の1つである「認証」について取り上げます。
ハッカーが有効なユーザー名とパスワードを使って管理者としてシステムにログインするだけであれば、ネットワーク防御に対抗するための高度な技術を導入する必要はありません。システムがドアを開けて攻撃者を侵入させるだけです。さらに悪いことに、攻撃者があまり突飛なことをしなければ、その存在を検知することはほとんど不可能です。なぜなら、ほとんどの防御システムは、攻撃者を有効なユーザーまたは管理者が自分の仕事をしていると見なすからです。
認証の脆弱性のカテゴリーは非常に大きいのですが、ここでは、ユーザーのログインプロセスに誤って組み込まれがちな、最も一般的な問題について説明します。これらの穴を塞ぐことで、認証に関する問題の大部分を組織から取り除くことができます。
このエピソードでは、以下のことを学びます。
- 一般的な認証の脆弱性がどのように利用されるか
- なぜ彼らは危険なのか
- 認証の脆弱性を排除するために、どのようなポリシーやテクニックを用いることができるか。
攻撃者はどのようにして認証の脆弱性を利用するのか？
認証システムに入り込む可能性のある認証の脆弱性は非常に多く、ハッカーはそれぞれの脆弱性を少しずつ悪用しています。まず、最も一般的な脆弱性について説明し、次にそれらの脆弱性がどのように悪用されるかを示す例を挙げてみましょう。
最も一般的な認証の脆弱性は以下の通りです。
- 弱いまたは不適切なパスワードポリシーを持つこと。
- 無制限のログイン試行を許可する。
- ログインに失敗したときに攻撃者に情報を提供する。
- 認証情報を安全でないチャンネルで送信すること。
- パスワードを弱くハッシュ化すること。
- そして、安全ではないパスワード回復プロセスを持っていること。
パスワードポリシーが脆弱であることは、最も一般的な脆弱性であると考えられます。ユーザーが何の制限もなくパスワードを作成できるとしたら、あまりにも多くのユーザーが簡単に推測可能なパスワードを使用してしまうでしょう。毎年、様々なコンピュータ関連の報道機関が「最も使われているパスワード」を発表していますが、「123456」や「password」は常にトップ5に入っています。他にもあります。管理者は「God」をよく使います。確かに、これらはどれもユーモアがあって覚えやすいですが、同時に非常に推測しやすいものでもあります。ハッカーは最も一般的なパスワードを知っていて、システムに侵入しようとするときにまずそれを試します。そのようなパスワードを許している組織では、いずれ侵入されてしまうでしょう。
あまり目立たないが、それでも危険な脆弱性は、ログインに失敗したときにユーザに情報を返すことです。これは、ユーザ名が存在しない場合に1つのメッセージを返し、ユーザ名は存在するがパスワードが不正である場合に別のメッセージを返すと、攻撃者がシステム上の有効なユーザをマッピングし、それらのユーザ名のためだけにパスワードを推測することに集中できるようになるからです。これが、パスワードを無制限に推測できる認証の脆弱性と組み合わさると、攻撃者は見つけた有効なユーザーに対して辞書攻撃を行うことが可能になり、パスワードが簡単に推測できる場合には、かなり早くシステムに侵入できるかもしれません。
認証の脆弱性はなぜ危険なのか？
アメリカの旧西部には、ある偏執狂的な開拓者の物語がある。彼は玄関に3重の鍵をかけ、窓を塞ぎ、たくさんの銃を手の届くところに置いて寝ていた。朝、彼は死体で発見された。裏口に鍵をかけるのを忘れたため、攻撃者に狙われてしまったのです。認証の脆弱性はそれとよく似ています。攻撃者が有効なユーザ名とパスワードを使ってネットワークに侵入することができれば、どのような監視ツールやプロアクティブなコントロールを導入していても、専門のアナリストをどれだけ雇っていても、実際には問題になりません。
いったん侵入してしまえば、攻撃者ができることにはほとんど制限がありません。管理者アカウントを侵害した場合には、かなり広範囲に及ぶユーザー権限の範囲内で行動する限り、深刻な問題を防ぐのに間に合うように攻撃者が捕まる可能性は非常に低くなります。このため、認証クラスの脆弱性は、あらゆるシステムで最も危険なものの1つとなっています。
認証の脆弱性を排除する
ネットワークから認証の脆弱性を排除する最良の方法の1つは、グローバルに施行される優れたパスワード・ポリシーを持つことです。ユーザーはもちろん、管理者であっても、「password」のようなパスワードの使用を制限するだけでなく、攻撃者が辞書攻撃や常套句攻撃を行うことができないような複雑なレベルのパスワードを追加する必要があります。保護するシステムの重要性に応じて、独自のパスワード作成のルールを作ることができます。そうすることで、攻撃者がパスワードを推測したり、ブルートフォース攻撃をしたりすることが非常に難しくなります。
また、不正なパスワードが3回以上入力された場合、ユーザーがロックアウトされるように、ログイン試行の失敗回数を制限する必要があります。ロックアウトは一時的なものでも構いません。数分遅れるだけで、自動化された辞書攻撃が続くのを防ぐことができます。また、管理者がアカウントのロックを解除しない限り、永久的にロックアウトされることもあります。いずれの場合も、このようなロックアウトが発生した場合には、セキュリティ担当者に警告し、状況を監視できるようにする必要があります。
攻撃者による情報収集を防ぐもう一つの良い方法は、不正なユーザー名またはパスワードが入力された場合に、一般的なメッセージを作成することです。ユーザーが存在しないために拒否されたのか、パスワードが間違っているために拒否されたのか、ハッカーにはわからないように、どちらの場合も同じメッセージを表示する必要があります。
認証の脆弱性は、ほとんどのシステムで最も一般的で危険なものの一つです。しかし、これらの脆弱性を発見し、排除することはかなり容易です。
認証の脆弱性に関する詳細情報
さらに読みたい方は、OWASP認証チートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Secure Code Warrior プラットフォームで認証の脆弱性に正面から向き合うステップアップ。[Start Here] (ここからスタート)
今回は、Webサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する、最も一般的な問題のひとつを取り上げます。そう、皆さんは「認証」の話をすることを想像しているでしょう。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
このブログでは、ウェブサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する最も一般的な問題の1つを取り上げます。このブログでは、Webサイトを運営している企業や、従業員がリモートでコンピュータリソースにアクセスする際に直面する最も一般的な問題の1つである「認証」について取り上げます。
ハッカーが有効なユーザー名とパスワードを使って管理者としてシステムにログインするだけであれば、ネットワーク防御に対抗するための高度な技術を導入する必要はありません。システムがドアを開けて攻撃者を侵入させるだけです。さらに悪いことに、攻撃者があまり突飛なことをしなければ、その存在を検知することはほとんど不可能です。なぜなら、ほとんどの防御システムは、攻撃者を有効なユーザーまたは管理者が自分の仕事をしていると見なすからです。
認証の脆弱性のカテゴリーは非常に大きいのですが、ここでは、ユーザーのログインプロセスに誤って組み込まれがちな、最も一般的な問題について説明します。これらの穴を塞ぐことで、認証に関する問題の大部分を組織から取り除くことができます。
このエピソードでは、以下のことを学びます。
- 一般的な認証の脆弱性がどのように利用されるか
- なぜ彼らは危険なのか
- 認証の脆弱性を排除するために、どのようなポリシーやテクニックを用いることができるか。
攻撃者はどのようにして認証の脆弱性を利用するのか？
認証システムに入り込む可能性のある認証の脆弱性は非常に多く、ハッカーはそれぞれの脆弱性を少しずつ悪用しています。まず、最も一般的な脆弱性について説明し、次にそれらの脆弱性がどのように悪用されるかを示す例を挙げてみましょう。
最も一般的な認証の脆弱性は以下の通りです。
- 弱いまたは不適切なパスワードポリシーを持つこと。
- 無制限のログイン試行を許可する。
- ログインに失敗したときに攻撃者に情報を提供する。
- 認証情報を安全でないチャンネルで送信すること。
- パスワードを弱くハッシュ化すること。
- そして、安全ではないパスワード回復プロセスを持っていること。
パスワードポリシーが脆弱であることは、最も一般的な脆弱性であると考えられます。ユーザーが何の制限もなくパスワードを作成できるとしたら、あまりにも多くのユーザーが簡単に推測可能なパスワードを使用してしまうでしょう。毎年、様々なコンピュータ関連の報道機関が「最も使われているパスワード」を発表していますが、「123456」や「password」は常にトップ5に入っています。他にもあります。管理者は「God」をよく使います。確かに、これらはどれもユーモアがあって覚えやすいですが、同時に非常に推測しやすいものでもあります。ハッカーは最も一般的なパスワードを知っていて、システムに侵入しようとするときにまずそれを試します。そのようなパスワードを許している組織では、いずれ侵入されてしまうでしょう。
あまり目立たないが、それでも危険な脆弱性は、ログインに失敗したときにユーザに情報を返すことです。これは、ユーザ名が存在しない場合に1つのメッセージを返し、ユーザ名は存在するがパスワードが不正である場合に別のメッセージを返すと、攻撃者がシステム上の有効なユーザをマッピングし、それらのユーザ名のためだけにパスワードを推測することに集中できるようになるからです。これが、パスワードを無制限に推測できる認証の脆弱性と組み合わさると、攻撃者は見つけた有効なユーザーに対して辞書攻撃を行うことが可能になり、パスワードが簡単に推測できる場合には、かなり早くシステムに侵入できるかもしれません。
認証の脆弱性はなぜ危険なのか？
アメリカの旧西部には、ある偏執狂的な開拓者の物語がある。彼は玄関に3重の鍵をかけ、窓を塞ぎ、たくさんの銃を手の届くところに置いて寝ていた。朝、彼は死体で発見された。裏口に鍵をかけるのを忘れたため、攻撃者に狙われてしまったのです。認証の脆弱性はそれとよく似ています。攻撃者が有効なユーザ名とパスワードを使ってネットワークに侵入することができれば、どのような監視ツールやプロアクティブなコントロールを導入していても、専門のアナリストをどれだけ雇っていても、実際には問題になりません。
いったん侵入してしまえば、攻撃者ができることにはほとんど制限がありません。管理者アカウントを侵害した場合には、かなり広範囲に及ぶユーザー権限の範囲内で行動する限り、深刻な問題を防ぐのに間に合うように攻撃者が捕まる可能性は非常に低くなります。このため、認証クラスの脆弱性は、あらゆるシステムで最も危険なものの1つとなっています。
認証の脆弱性を排除する
ネットワークから認証の脆弱性を排除する最良の方法の1つは、グローバルに施行される優れたパスワード・ポリシーを持つことです。ユーザーはもちろん、管理者であっても、「password」のようなパスワードの使用を制限するだけでなく、攻撃者が辞書攻撃や常套句攻撃を行うことができないような複雑なレベルのパスワードを追加する必要があります。保護するシステムの重要性に応じて、独自のパスワード作成のルールを作ることができます。そうすることで、攻撃者がパスワードを推測したり、ブルートフォース攻撃をしたりすることが非常に難しくなります。
また、不正なパスワードが3回以上入力された場合、ユーザーがロックアウトされるように、ログイン試行の失敗回数を制限する必要があります。ロックアウトは一時的なものでも構いません。数分遅れるだけで、自動化された辞書攻撃が続くのを防ぐことができます。また、管理者がアカウントのロックを解除しない限り、永久的にロックアウトされることもあります。いずれの場合も、このようなロックアウトが発生した場合には、セキュリティ担当者に警告し、状況を監視できるようにする必要があります。
攻撃者による情報収集を防ぐもう一つの良い方法は、不正なユーザー名またはパスワードが入力された場合に、一般的なメッセージを作成することです。ユーザーが存在しないために拒否されたのか、パスワードが間違っているために拒否されたのか、ハッカーにはわからないように、どちらの場合も同じメッセージを表示する必要があります。
認証の脆弱性は、ほとんどのシステムで最も一般的で危険なものの一つです。しかし、これらの脆弱性を発見し、排除することはかなり容易です。
認証の脆弱性に関する詳細情報
さらに読みたい方は、OWASP認証チートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Secure Code Warrior プラットフォームで認証の脆弱性に正面から向き合うステップアップ。[Start Here] (ここからスタート)
このブログでは、ウェブサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する最も一般的な問題の1つを取り上げます。このブログでは、Webサイトを運営している企業や、従業員がリモートでコンピュータリソースにアクセスする際に直面する最も一般的な問題の1つである「認証」について取り上げます。
ハッカーが有効なユーザー名とパスワードを使って管理者としてシステムにログインするだけであれば、ネットワーク防御に対抗するための高度な技術を導入する必要はありません。システムがドアを開けて攻撃者を侵入させるだけです。さらに悪いことに、攻撃者があまり突飛なことをしなければ、その存在を検知することはほとんど不可能です。なぜなら、ほとんどの防御システムは、攻撃者を有効なユーザーまたは管理者が自分の仕事をしていると見なすからです。
認証の脆弱性のカテゴリーは非常に大きいのですが、ここでは、ユーザーのログインプロセスに誤って組み込まれがちな、最も一般的な問題について説明します。これらの穴を塞ぐことで、認証に関する問題の大部分を組織から取り除くことができます。
このエピソードでは、以下のことを学びます。
- 一般的な認証の脆弱性がどのように利用されるか
- なぜ彼らは危険なのか
- 認証の脆弱性を排除するために、どのようなポリシーやテクニックを用いることができるか。
攻撃者はどのようにして認証の脆弱性を利用するのか？
認証システムに入り込む可能性のある認証の脆弱性は非常に多く、ハッカーはそれぞれの脆弱性を少しずつ悪用しています。まず、最も一般的な脆弱性について説明し、次にそれらの脆弱性がどのように悪用されるかを示す例を挙げてみましょう。
最も一般的な認証の脆弱性は以下の通りです。
- 弱いまたは不適切なパスワードポリシーを持つこと。
- 無制限のログイン試行を許可する。
- ログインに失敗したときに攻撃者に情報を提供する。
- 認証情報を安全でないチャンネルで送信すること。
- パスワードを弱くハッシュ化すること。
- そして、安全ではないパスワード回復プロセスを持っていること。
パスワードポリシーが脆弱であることは、最も一般的な脆弱性であると考えられます。ユーザーが何の制限もなくパスワードを作成できるとしたら、あまりにも多くのユーザーが簡単に推測可能なパスワードを使用してしまうでしょう。毎年、様々なコンピュータ関連の報道機関が「最も使われているパスワード」を発表していますが、「123456」や「password」は常にトップ5に入っています。他にもあります。管理者は「God」をよく使います。確かに、これらはどれもユーモアがあって覚えやすいですが、同時に非常に推測しやすいものでもあります。ハッカーは最も一般的なパスワードを知っていて、システムに侵入しようとするときにまずそれを試します。そのようなパスワードを許している組織では、いずれ侵入されてしまうでしょう。
あまり目立たないが、それでも危険な脆弱性は、ログインに失敗したときにユーザに情報を返すことです。これは、ユーザ名が存在しない場合に1つのメッセージを返し、ユーザ名は存在するがパスワードが不正である場合に別のメッセージを返すと、攻撃者がシステム上の有効なユーザをマッピングし、それらのユーザ名のためだけにパスワードを推測することに集中できるようになるからです。これが、パスワードを無制限に推測できる認証の脆弱性と組み合わさると、攻撃者は見つけた有効なユーザーに対して辞書攻撃を行うことが可能になり、パスワードが簡単に推測できる場合には、かなり早くシステムに侵入できるかもしれません。
認証の脆弱性はなぜ危険なのか？
アメリカの旧西部には、ある偏執狂的な開拓者の物語がある。彼は玄関に3重の鍵をかけ、窓を塞ぎ、たくさんの銃を手の届くところに置いて寝ていた。朝、彼は死体で発見された。裏口に鍵をかけるのを忘れたため、攻撃者に狙われてしまったのです。認証の脆弱性はそれとよく似ています。攻撃者が有効なユーザ名とパスワードを使ってネットワークに侵入することができれば、どのような監視ツールやプロアクティブなコントロールを導入していても、専門のアナリストをどれだけ雇っていても、実際には問題になりません。
いったん侵入してしまえば、攻撃者ができることにはほとんど制限がありません。管理者アカウントを侵害した場合には、かなり広範囲に及ぶユーザー権限の範囲内で行動する限り、深刻な問題を防ぐのに間に合うように攻撃者が捕まる可能性は非常に低くなります。このため、認証クラスの脆弱性は、あらゆるシステムで最も危険なものの1つとなっています。
認証の脆弱性を排除する
ネットワークから認証の脆弱性を排除する最良の方法の1つは、グローバルに施行される優れたパスワード・ポリシーを持つことです。ユーザーはもちろん、管理者であっても、「password」のようなパスワードの使用を制限するだけでなく、攻撃者が辞書攻撃や常套句攻撃を行うことができないような複雑なレベルのパスワードを追加する必要があります。保護するシステムの重要性に応じて、独自のパスワード作成のルールを作ることができます。そうすることで、攻撃者がパスワードを推測したり、ブルートフォース攻撃をしたりすることが非常に難しくなります。
また、不正なパスワードが3回以上入力された場合、ユーザーがロックアウトされるように、ログイン試行の失敗回数を制限する必要があります。ロックアウトは一時的なものでも構いません。数分遅れるだけで、自動化された辞書攻撃が続くのを防ぐことができます。また、管理者がアカウントのロックを解除しない限り、永久的にロックアウトされることもあります。いずれの場合も、このようなロックアウトが発生した場合には、セキュリティ担当者に警告し、状況を監視できるようにする必要があります。
攻撃者による情報収集を防ぐもう一つの良い方法は、不正なユーザー名またはパスワードが入力された場合に、一般的なメッセージを作成することです。ユーザーが存在しないために拒否されたのか、パスワードが間違っているために拒否されたのか、ハッカーにはわからないように、どちらの場合も同じメッセージを表示する必要があります。
認証の脆弱性は、ほとんどのシステムで最も一般的で危険なものの一つです。しかし、これらの脆弱性を発見し、排除することはかなり容易です。
認証の脆弱性に関する詳細情報
さらに読みたい方は、OWASP認証チートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Secure Code Warrior プラットフォームで認証の脆弱性に正面から向き合うステップアップ。[Start Here] (ここからスタート)
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
このブログでは、ウェブサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する最も一般的な問題の1つを取り上げます。このブログでは、Webサイトを運営している企業や、従業員がリモートでコンピュータリソースにアクセスする際に直面する最も一般的な問題の1つである「認証」について取り上げます。
ハッカーが有効なユーザー名とパスワードを使って管理者としてシステムにログインするだけであれば、ネットワーク防御に対抗するための高度な技術を導入する必要はありません。システムがドアを開けて攻撃者を侵入させるだけです。さらに悪いことに、攻撃者があまり突飛なことをしなければ、その存在を検知することはほとんど不可能です。なぜなら、ほとんどの防御システムは、攻撃者を有効なユーザーまたは管理者が自分の仕事をしていると見なすからです。
認証の脆弱性のカテゴリーは非常に大きいのですが、ここでは、ユーザーのログインプロセスに誤って組み込まれがちな、最も一般的な問題について説明します。これらの穴を塞ぐことで、認証に関する問題の大部分を組織から取り除くことができます。
このエピソードでは、以下のことを学びます。
- 一般的な認証の脆弱性がどのように利用されるか
- なぜ彼らは危険なのか
- 認証の脆弱性を排除するために、どのようなポリシーやテクニックを用いることができるか。
攻撃者はどのようにして認証の脆弱性を利用するのか？
認証システムに入り込む可能性のある認証の脆弱性は非常に多く、ハッカーはそれぞれの脆弱性を少しずつ悪用しています。まず、最も一般的な脆弱性について説明し、次にそれらの脆弱性がどのように悪用されるかを示す例を挙げてみましょう。
最も一般的な認証の脆弱性は以下の通りです。
- 弱いまたは不適切なパスワードポリシーを持つこと。
- 無制限のログイン試行を許可する。
- ログインに失敗したときに攻撃者に情報を提供する。
- 認証情報を安全でないチャンネルで送信すること。
- パスワードを弱くハッシュ化すること。
- そして、安全ではないパスワード回復プロセスを持っていること。
パスワードポリシーが脆弱であることは、最も一般的な脆弱性であると考えられます。ユーザーが何の制限もなくパスワードを作成できるとしたら、あまりにも多くのユーザーが簡単に推測可能なパスワードを使用してしまうでしょう。毎年、様々なコンピュータ関連の報道機関が「最も使われているパスワード」を発表していますが、「123456」や「password」は常にトップ5に入っています。他にもあります。管理者は「God」をよく使います。確かに、これらはどれもユーモアがあって覚えやすいですが、同時に非常に推測しやすいものでもあります。ハッカーは最も一般的なパスワードを知っていて、システムに侵入しようとするときにまずそれを試します。そのようなパスワードを許している組織では、いずれ侵入されてしまうでしょう。
あまり目立たないが、それでも危険な脆弱性は、ログインに失敗したときにユーザに情報を返すことです。これは、ユーザ名が存在しない場合に1つのメッセージを返し、ユーザ名は存在するがパスワードが不正である場合に別のメッセージを返すと、攻撃者がシステム上の有効なユーザをマッピングし、それらのユーザ名のためだけにパスワードを推測することに集中できるようになるからです。これが、パスワードを無制限に推測できる認証の脆弱性と組み合わさると、攻撃者は見つけた有効なユーザーに対して辞書攻撃を行うことが可能になり、パスワードが簡単に推測できる場合には、かなり早くシステムに侵入できるかもしれません。
認証の脆弱性はなぜ危険なのか？
アメリカの旧西部には、ある偏執狂的な開拓者の物語がある。彼は玄関に3重の鍵をかけ、窓を塞ぎ、たくさんの銃を手の届くところに置いて寝ていた。朝、彼は死体で発見された。裏口に鍵をかけるのを忘れたため、攻撃者に狙われてしまったのです。認証の脆弱性はそれとよく似ています。攻撃者が有効なユーザ名とパスワードを使ってネットワークに侵入することができれば、どのような監視ツールやプロアクティブなコントロールを導入していても、専門のアナリストをどれだけ雇っていても、実際には問題になりません。
いったん侵入してしまえば、攻撃者ができることにはほとんど制限がありません。管理者アカウントを侵害した場合には、かなり広範囲に及ぶユーザー権限の範囲内で行動する限り、深刻な問題を防ぐのに間に合うように攻撃者が捕まる可能性は非常に低くなります。このため、認証クラスの脆弱性は、あらゆるシステムで最も危険なものの1つとなっています。
認証の脆弱性を排除する
ネットワークから認証の脆弱性を排除する最良の方法の1つは、グローバルに施行される優れたパスワード・ポリシーを持つことです。ユーザーはもちろん、管理者であっても、「password」のようなパスワードの使用を制限するだけでなく、攻撃者が辞書攻撃や常套句攻撃を行うことができないような複雑なレベルのパスワードを追加する必要があります。保護するシステムの重要性に応じて、独自のパスワード作成のルールを作ることができます。そうすることで、攻撃者がパスワードを推測したり、ブルートフォース攻撃をしたりすることが非常に難しくなります。
また、不正なパスワードが3回以上入力された場合、ユーザーがロックアウトされるように、ログイン試行の失敗回数を制限する必要があります。ロックアウトは一時的なものでも構いません。数分遅れるだけで、自動化された辞書攻撃が続くのを防ぐことができます。また、管理者がアカウントのロックを解除しない限り、永久的にロックアウトされることもあります。いずれの場合も、このようなロックアウトが発生した場合には、セキュリティ担当者に警告し、状況を監視できるようにする必要があります。
攻撃者による情報収集を防ぐもう一つの良い方法は、不正なユーザー名またはパスワードが入力された場合に、一般的なメッセージを作成することです。ユーザーが存在しないために拒否されたのか、パスワードが間違っているために拒否されたのか、ハッカーにはわからないように、どちらの場合も同じメッセージを表示する必要があります。
認証の脆弱性は、ほとんどのシステムで最も一般的で危険なものの一つです。しかし、これらの脆弱性を発見し、排除することはかなり容易です。
認証の脆弱性に関する詳細情報
さらに読みたい方は、OWASP認証チートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Secure Code Warrior プラットフォームで認証の脆弱性に正面から向き合うステップアップ。[Start Here] (ここからスタート)
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
