Coders Conquer Security:シェア＆ラーンシリーズ - LDAPインジェクション
ほとんどのコンピューターシステムでは、LDAP（Lightweight Directory Access Protocol）が使われている。LDAPは、インターネット・プロトコル（IP）ネットワーク上で分散型ディレクトリ情報サービスを維持するために使用されます。つまり、基本的にはユーザーを管理するための手段として機能しています。
LDAPは、アプリケーションがユーザーに様々なアクションを実行する権限があるかどうか、特に組織内で定義された役割に関連しているかどうかを確認するための認証ソースとしてよく使用される。例えば、経理担当者だけが会社の会計ソフトを使えるようになっているかもしれない。アプリケーションは、LDAPテーブルをチェックして、ユーザーが確立された権限の範囲内で行動していることを確認するようにプログラムされることが多い。
悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。
LDAPインジェクションは厄介なものですが、このエピソードでは、それを学びます。
- 仕組み
- なぜ彼らは危険なのか
- それを阻止するためには、どのような防御策を講じるべきか。
攻撃者はどのようにLDAPインジェクションを利用するのか？
LDAPベースの攻撃が長年にわたって人気を維持している理由の1つは、ほとんどすべてのコンピュータシステムがLDAPを使用しているという事実です。LDAPはオープンソースで、非常によく機能するため、代替手段があまり作られていません。
LDAPは、IPベースのコンピューターシステムやネットワーク内の有効なユーザーを追跡するデータベースであることがその核心である。ユーザーは、システム、ネットワーク、サーバー、アプリケーション、さらには同じネットワーク上の他のユーザーに関する情報を共有することができます。
LDAPでは、データベースの行やレコードに相当する情報が保存されており、これを識別名と呼びます。各DNはユニークです。例として、大企業のシカゴ会計事務所に勤務するユーザーのDNは次のようになります。
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
各 DN が一意であることを保証するために、レコードに「+」、「/」、「=」などのさまざまなコードを追加することができます。また、レコードの前後にスペースを挿入することで、シカゴ・パークビューオフィスのコーポレートアカウントで働くジェームス・スミスが2人いたとしても、それぞれが個別のDNを持つことができます。
アプリケーションでは一般的にLDAPを使用して、ユーザーが特定のDNに関するクエリを送信できるようにしています。例えば、小切手にミスがあったことを相談するために、給与部の正しい連絡先を見つけようとする場合などです。LDAPインジェクションは、検索クエリでユーザーが提供したパラメータの検証が行われていない場合に起こる可能性があります。その場合、ハッカーは良性の検索を操作して、認証メカニズムを回避したり、追加の任意のクエリを実行したりすることができます。これにより、サーバーを騙して、ユーザーのパスワードなど許可されていないはずの結果を表示させたり、有効なパスワードの有無にかかわらず、ネットワーク内のセキュリティの高い領域へのアクセスをアプリケーションに許可させたりすることができます。
なぜLDAPインジェクションは危険なのか？
LDAPインジェクションの最大の危険性は、世界中の大半のIPコンピュータ・ネットワークにLDAPプロトコルが普及していることにある。情報を盗んだり、ネットワーク上で自分の権限を高めたりしたいと考えているハッカーにとって、LDAPは容易な足がかりとなる。訓練されたハッカーであれば、LDAPインジェクションが可能かどうかをチェックしないことはないので、セキュリティチームはその穴が常に閉じられていることを確認しなければならない。
具体的には、組織内のユーザーやグループに関する限定的な情報、あるいはDNに含まれるその他の情報を、有効なユーザーが見つけられるようにプログラムされたアプリケーションがかなりある。例えば、あるアプリケーションでは、LDAPを使ってシカゴで働く企業の会計士の連絡先情報を検索できるようになっており、上記の例では友人のJames Smithが返される。パーミッションにもよりますが、これはLDAPクエリーの完全に有効な使用法と言えます。
危険なのは、悪意のあるユーザがクエリにフィルタリングされていないパラメータを追加し、検索の性質を変え、通常は提供されるべきでない情報を提供するようにサーバを騙した場合です。例えば、user=*という文字列を追加すると、攻撃者は、組織全体のすべてのユーザーに関する情報を取得することができます。
認証にLDAPを使用しているアプリケーションでは、問題はさらに悪化する可能性があります。攻撃者は、例えば、LDAP クエリの最後にある (&) 文字列を使用して、引数が真であるとサーバーに思わせることができます。アプリケーションがパスワードの検証にLDAPを使用している場合、LDAPインジェクションによって引数を強制的にTrueにすると、パスワードがなくても、権限のないユーザーが管理者としてネットワークにログインできる可能性があります。
ネットワークでLDAPインジェクションをL-DON'Tにする
LDAPインジェクションを防止する最善の方法の1つは、LINQtoADなど、LDAPインジェクションに対抗するために特別に設計されたフレームワークを実装することです。ネットワーク上にLDAPクエリを利用するアプリケーションがすでに存在する場合は、これができないこともある。しかし、そのような場合でも、新しいアプリケーションには、インジェクション耐性のあるフレームワークを使用することをお勧めします。
LDAPを使用する既存のアプリケーションでも、ホワイトリストの検証や入力のサニタイズを行うことで、インジェクションに対する耐性を高めることができます。可能であれば、ユーザーの入力を限られた信頼できる値のセットに制限してください。そうでない場合は、LDAP クエリの一部であるユーザーの入力を最初にサニタイズする必要があります。また、GET および POST パラメータ、Cookie、HTTP ヘッダーも攻撃のベクターとして機能することがあるので、これらを含めることを忘れないでください。入力のサニタイズを行うために独自の関数を書かないでください。代わりに、信頼できるサードパーティのセキュリティに特化したライブラリやフレームワークの組み込みAPIを使用してください。
対象となる対策だけでなく、ネットワーク上で必要最小限の権限を持つLDAP照会アプリケーションを割り当てるなど、適切なコンピューティング・プラクティスを行うことも有効です。これにより、万が一、LDAPインジェクションが通過してしまった場合でも、その被害を軽減することができます。
LDAPインジェクションの詳細情報
さらに読みたい方は、OWASP の LDAP インジェクションに関する記事や、インジェクション防止のためのチートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。
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 の共同設立者です。
ほとんどのコンピューターシステムでは、LDAP（Lightweight Directory Access Protocol）が使われている。LDAPは、インターネット・プロトコル（IP）ネットワーク上で分散型ディレクトリ情報サービスを維持するために使用されます。つまり、基本的にはユーザーを管理するための手段として機能しています。
LDAPは、アプリケーションがユーザーに様々なアクションを実行する権限があるかどうか、特に組織内で定義された役割に関連しているかどうかを確認するための認証ソースとしてよく使用される。例えば、経理担当者だけが会社の会計ソフトを使えるようになっているかもしれない。アプリケーションは、LDAPテーブルをチェックして、ユーザーが確立された権限の範囲内で行動していることを確認するようにプログラムされることが多い。
悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。
LDAPインジェクションは厄介なものですが、このエピソードでは、それを学びます。
- 仕組み
- なぜ彼らは危険なのか
- それを阻止するためには、どのような防御策を講じるべきか。
攻撃者はどのようにLDAPインジェクションを利用するのか？
LDAPベースの攻撃が長年にわたって人気を維持している理由の1つは、ほとんどすべてのコンピュータシステムがLDAPを使用しているという事実です。LDAPはオープンソースで、非常によく機能するため、代替手段があまり作られていません。
LDAPは、IPベースのコンピューターシステムやネットワーク内の有効なユーザーを追跡するデータベースであることがその核心である。ユーザーは、システム、ネットワーク、サーバー、アプリケーション、さらには同じネットワーク上の他のユーザーに関する情報を共有することができます。
LDAPでは、データベースの行やレコードに相当する情報が保存されており、これを識別名と呼びます。各DNはユニークです。例として、大企業のシカゴ会計事務所に勤務するユーザーのDNは次のようになります。
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
各 DN が一意であることを保証するために、レコードに「+」、「/」、「=」などのさまざまなコードを追加することができます。また、レコードの前後にスペースを挿入することで、シカゴ・パークビューオフィスのコーポレートアカウントで働くジェームス・スミスが2人いたとしても、それぞれが個別のDNを持つことができます。
アプリケーションでは一般的にLDAPを使用して、ユーザーが特定のDNに関するクエリを送信できるようにしています。例えば、小切手にミスがあったことを相談するために、給与部の正しい連絡先を見つけようとする場合などです。LDAPインジェクションは、検索クエリでユーザーが提供したパラメータの検証が行われていない場合に起こる可能性があります。その場合、ハッカーは良性の検索を操作して、認証メカニズムを回避したり、追加の任意のクエリを実行したりすることができます。これにより、サーバーを騙して、ユーザーのパスワードなど許可されていないはずの結果を表示させたり、有効なパスワードの有無にかかわらず、ネットワーク内のセキュリティの高い領域へのアクセスをアプリケーションに許可させたりすることができます。
なぜLDAPインジェクションは危険なのか？
LDAPインジェクションの最大の危険性は、世界中の大半のIPコンピュータ・ネットワークにLDAPプロトコルが普及していることにある。情報を盗んだり、ネットワーク上で自分の権限を高めたりしたいと考えているハッカーにとって、LDAPは容易な足がかりとなる。訓練されたハッカーであれば、LDAPインジェクションが可能かどうかをチェックしないことはないので、セキュリティチームはその穴が常に閉じられていることを確認しなければならない。
具体的には、組織内のユーザーやグループに関する限定的な情報、あるいはDNに含まれるその他の情報を、有効なユーザーが見つけられるようにプログラムされたアプリケーションがかなりある。例えば、あるアプリケーションでは、LDAPを使ってシカゴで働く企業の会計士の連絡先情報を検索できるようになっており、上記の例では友人のJames Smithが返される。パーミッションにもよりますが、これはLDAPクエリーの完全に有効な使用法と言えます。
危険なのは、悪意のあるユーザがクエリにフィルタリングされていないパラメータを追加し、検索の性質を変え、通常は提供されるべきでない情報を提供するようにサーバを騙した場合です。例えば、user=*という文字列を追加すると、攻撃者は、組織全体のすべてのユーザーに関する情報を取得することができます。
認証にLDAPを使用しているアプリケーションでは、問題はさらに悪化する可能性があります。攻撃者は、例えば、LDAP クエリの最後にある (&) 文字列を使用して、引数が真であるとサーバーに思わせることができます。アプリケーションがパスワードの検証にLDAPを使用している場合、LDAPインジェクションによって引数を強制的にTrueにすると、パスワードがなくても、権限のないユーザーが管理者としてネットワークにログインできる可能性があります。
ネットワークでLDAPインジェクションをL-DON'Tにする
LDAPインジェクションを防止する最善の方法の1つは、LINQtoADなど、LDAPインジェクションに対抗するために特別に設計されたフレームワークを実装することです。ネットワーク上にLDAPクエリを利用するアプリケーションがすでに存在する場合は、これができないこともある。しかし、そのような場合でも、新しいアプリケーションには、インジェクション耐性のあるフレームワークを使用することをお勧めします。
LDAPを使用する既存のアプリケーションでも、ホワイトリストの検証や入力のサニタイズを行うことで、インジェクションに対する耐性を高めることができます。可能であれば、ユーザーの入力を限られた信頼できる値のセットに制限してください。そうでない場合は、LDAP クエリの一部であるユーザーの入力を最初にサニタイズする必要があります。また、GET および POST パラメータ、Cookie、HTTP ヘッダーも攻撃のベクターとして機能することがあるので、これらを含めることを忘れないでください。入力のサニタイズを行うために独自の関数を書かないでください。代わりに、信頼できるサードパーティのセキュリティに特化したライブラリやフレームワークの組み込みAPIを使用してください。
対象となる対策だけでなく、ネットワーク上で必要最小限の権限を持つLDAP照会アプリケーションを割り当てるなど、適切なコンピューティング・プラクティスを行うことも有効です。これにより、万が一、LDAPインジェクションが通過してしまった場合でも、その被害を軽減することができます。
LDAPインジェクションの詳細情報
さらに読みたい方は、OWASP の LDAP インジェクションに関する記事や、インジェクション防止のためのチートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
ほとんどのコンピューターシステムでは、LDAP（Lightweight Directory Access Protocol）が使われている。LDAPは、インターネット・プロトコル（IP）ネットワーク上で分散型ディレクトリ情報サービスを維持するために使用されます。つまり、基本的にはユーザーを管理するための手段として機能しています。
LDAPは、アプリケーションがユーザーに様々なアクションを実行する権限があるかどうか、特に組織内で定義された役割に関連しているかどうかを確認するための認証ソースとしてよく使用される。例えば、経理担当者だけが会社の会計ソフトを使えるようになっているかもしれない。アプリケーションは、LDAPテーブルをチェックして、ユーザーが確立された権限の範囲内で行動していることを確認するようにプログラムされることが多い。
悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。
LDAPインジェクションは厄介なものですが、このエピソードでは、それを学びます。
- 仕組み
- なぜ彼らは危険なのか
- それを阻止するためには、どのような防御策を講じるべきか。
攻撃者はどのようにLDAPインジェクションを利用するのか？
LDAPベースの攻撃が長年にわたって人気を維持している理由の1つは、ほとんどすべてのコンピュータシステムがLDAPを使用しているという事実です。LDAPはオープンソースで、非常によく機能するため、代替手段があまり作られていません。
LDAPは、IPベースのコンピューターシステムやネットワーク内の有効なユーザーを追跡するデータベースであることがその核心である。ユーザーは、システム、ネットワーク、サーバー、アプリケーション、さらには同じネットワーク上の他のユーザーに関する情報を共有することができます。
LDAPでは、データベースの行やレコードに相当する情報が保存されており、これを識別名と呼びます。各DNはユニークです。例として、大企業のシカゴ会計事務所に勤務するユーザーのDNは次のようになります。
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
各 DN が一意であることを保証するために、レコードに「+」、「/」、「=」などのさまざまなコードを追加することができます。また、レコードの前後にスペースを挿入することで、シカゴ・パークビューオフィスのコーポレートアカウントで働くジェームス・スミスが2人いたとしても、それぞれが個別のDNを持つことができます。
アプリケーションでは一般的にLDAPを使用して、ユーザーが特定のDNに関するクエリを送信できるようにしています。例えば、小切手にミスがあったことを相談するために、給与部の正しい連絡先を見つけようとする場合などです。LDAPインジェクションは、検索クエリでユーザーが提供したパラメータの検証が行われていない場合に起こる可能性があります。その場合、ハッカーは良性の検索を操作して、認証メカニズムを回避したり、追加の任意のクエリを実行したりすることができます。これにより、サーバーを騙して、ユーザーのパスワードなど許可されていないはずの結果を表示させたり、有効なパスワードの有無にかかわらず、ネットワーク内のセキュリティの高い領域へのアクセスをアプリケーションに許可させたりすることができます。
なぜLDAPインジェクションは危険なのか？
LDAPインジェクションの最大の危険性は、世界中の大半のIPコンピュータ・ネットワークにLDAPプロトコルが普及していることにある。情報を盗んだり、ネットワーク上で自分の権限を高めたりしたいと考えているハッカーにとって、LDAPは容易な足がかりとなる。訓練されたハッカーであれば、LDAPインジェクションが可能かどうかをチェックしないことはないので、セキュリティチームはその穴が常に閉じられていることを確認しなければならない。
具体的には、組織内のユーザーやグループに関する限定的な情報、あるいはDNに含まれるその他の情報を、有効なユーザーが見つけられるようにプログラムされたアプリケーションがかなりある。例えば、あるアプリケーションでは、LDAPを使ってシカゴで働く企業の会計士の連絡先情報を検索できるようになっており、上記の例では友人のJames Smithが返される。パーミッションにもよりますが、これはLDAPクエリーの完全に有効な使用法と言えます。
危険なのは、悪意のあるユーザがクエリにフィルタリングされていないパラメータを追加し、検索の性質を変え、通常は提供されるべきでない情報を提供するようにサーバを騙した場合です。例えば、user=*という文字列を追加すると、攻撃者は、組織全体のすべてのユーザーに関する情報を取得することができます。
認証にLDAPを使用しているアプリケーションでは、問題はさらに悪化する可能性があります。攻撃者は、例えば、LDAP クエリの最後にある (&) 文字列を使用して、引数が真であるとサーバーに思わせることができます。アプリケーションがパスワードの検証にLDAPを使用している場合、LDAPインジェクションによって引数を強制的にTrueにすると、パスワードがなくても、権限のないユーザーが管理者としてネットワークにログインできる可能性があります。
ネットワークでLDAPインジェクションをL-DON'Tにする
LDAPインジェクションを防止する最善の方法の1つは、LINQtoADなど、LDAPインジェクションに対抗するために特別に設計されたフレームワークを実装することです。ネットワーク上にLDAPクエリを利用するアプリケーションがすでに存在する場合は、これができないこともある。しかし、そのような場合でも、新しいアプリケーションには、インジェクション耐性のあるフレームワークを使用することをお勧めします。
LDAPを使用する既存のアプリケーションでも、ホワイトリストの検証や入力のサニタイズを行うことで、インジェクションに対する耐性を高めることができます。可能であれば、ユーザーの入力を限られた信頼できる値のセットに制限してください。そうでない場合は、LDAP クエリの一部であるユーザーの入力を最初にサニタイズする必要があります。また、GET および POST パラメータ、Cookie、HTTP ヘッダーも攻撃のベクターとして機能することがあるので、これらを含めることを忘れないでください。入力のサニタイズを行うために独自の関数を書かないでください。代わりに、信頼できるサードパーティのセキュリティに特化したライブラリやフレームワークの組み込みAPIを使用してください。
対象となる対策だけでなく、ネットワーク上で必要最小限の権限を持つLDAP照会アプリケーションを割り当てるなど、適切なコンピューティング・プラクティスを行うことも有効です。これにより、万が一、LDAPインジェクションが通過してしまった場合でも、その被害を軽減することができます。
LDAPインジェクションの詳細情報
さらに読みたい方は、OWASP の LDAP インジェクションに関する記事や、インジェクション防止のためのチートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
ほとんどのコンピューターシステムでは、LDAP（Lightweight Directory Access Protocol）が使われている。LDAPは、インターネット・プロトコル（IP）ネットワーク上で分散型ディレクトリ情報サービスを維持するために使用されます。つまり、基本的にはユーザーを管理するための手段として機能しています。
LDAPは、アプリケーションがユーザーに様々なアクションを実行する権限があるかどうか、特に組織内で定義された役割に関連しているかどうかを確認するための認証ソースとしてよく使用される。例えば、経理担当者だけが会社の会計ソフトを使えるようになっているかもしれない。アプリケーションは、LDAPテーブルをチェックして、ユーザーが確立された権限の範囲内で行動していることを確認するようにプログラムされることが多い。
悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。
LDAPインジェクションは厄介なものですが、このエピソードでは、それを学びます。
- 仕組み
- なぜ彼らは危険なのか
- それを阻止するためには、どのような防御策を講じるべきか。
攻撃者はどのようにLDAPインジェクションを利用するのか？
LDAPベースの攻撃が長年にわたって人気を維持している理由の1つは、ほとんどすべてのコンピュータシステムがLDAPを使用しているという事実です。LDAPはオープンソースで、非常によく機能するため、代替手段があまり作られていません。
LDAPは、IPベースのコンピューターシステムやネットワーク内の有効なユーザーを追跡するデータベースであることがその核心である。ユーザーは、システム、ネットワーク、サーバー、アプリケーション、さらには同じネットワーク上の他のユーザーに関する情報を共有することができます。
LDAPでは、データベースの行やレコードに相当する情報が保存されており、これを識別名と呼びます。各DNはユニークです。例として、大企業のシカゴ会計事務所に勤務するユーザーのDNは次のようになります。
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
各 DN が一意であることを保証するために、レコードに「+」、「/」、「=」などのさまざまなコードを追加することができます。また、レコードの前後にスペースを挿入することで、シカゴ・パークビューオフィスのコーポレートアカウントで働くジェームス・スミスが2人いたとしても、それぞれが個別のDNを持つことができます。
アプリケーションでは一般的にLDAPを使用して、ユーザーが特定のDNに関するクエリを送信できるようにしています。例えば、小切手にミスがあったことを相談するために、給与部の正しい連絡先を見つけようとする場合などです。LDAPインジェクションは、検索クエリでユーザーが提供したパラメータの検証が行われていない場合に起こる可能性があります。その場合、ハッカーは良性の検索を操作して、認証メカニズムを回避したり、追加の任意のクエリを実行したりすることができます。これにより、サーバーを騙して、ユーザーのパスワードなど許可されていないはずの結果を表示させたり、有効なパスワードの有無にかかわらず、ネットワーク内のセキュリティの高い領域へのアクセスをアプリケーションに許可させたりすることができます。
なぜLDAPインジェクションは危険なのか？
LDAPインジェクションの最大の危険性は、世界中の大半のIPコンピュータ・ネットワークにLDAPプロトコルが普及していることにある。情報を盗んだり、ネットワーク上で自分の権限を高めたりしたいと考えているハッカーにとって、LDAPは容易な足がかりとなる。訓練されたハッカーであれば、LDAPインジェクションが可能かどうかをチェックしないことはないので、セキュリティチームはその穴が常に閉じられていることを確認しなければならない。
具体的には、組織内のユーザーやグループに関する限定的な情報、あるいはDNに含まれるその他の情報を、有効なユーザーが見つけられるようにプログラムされたアプリケーションがかなりある。例えば、あるアプリケーションでは、LDAPを使ってシカゴで働く企業の会計士の連絡先情報を検索できるようになっており、上記の例では友人のJames Smithが返される。パーミッションにもよりますが、これはLDAPクエリーの完全に有効な使用法と言えます。
危険なのは、悪意のあるユーザがクエリにフィルタリングされていないパラメータを追加し、検索の性質を変え、通常は提供されるべきでない情報を提供するようにサーバを騙した場合です。例えば、user=*という文字列を追加すると、攻撃者は、組織全体のすべてのユーザーに関する情報を取得することができます。
認証にLDAPを使用しているアプリケーションでは、問題はさらに悪化する可能性があります。攻撃者は、例えば、LDAP クエリの最後にある (&) 文字列を使用して、引数が真であるとサーバーに思わせることができます。アプリケーションがパスワードの検証にLDAPを使用している場合、LDAPインジェクションによって引数を強制的にTrueにすると、パスワードがなくても、権限のないユーザーが管理者としてネットワークにログインできる可能性があります。
ネットワークでLDAPインジェクションをL-DON'Tにする
LDAPインジェクションを防止する最善の方法の1つは、LINQtoADなど、LDAPインジェクションに対抗するために特別に設計されたフレームワークを実装することです。ネットワーク上にLDAPクエリを利用するアプリケーションがすでに存在する場合は、これができないこともある。しかし、そのような場合でも、新しいアプリケーションには、インジェクション耐性のあるフレームワークを使用することをお勧めします。
LDAPを使用する既存のアプリケーションでも、ホワイトリストの検証や入力のサニタイズを行うことで、インジェクションに対する耐性を高めることができます。可能であれば、ユーザーの入力を限られた信頼できる値のセットに制限してください。そうでない場合は、LDAP クエリの一部であるユーザーの入力を最初にサニタイズする必要があります。また、GET および POST パラメータ、Cookie、HTTP ヘッダーも攻撃のベクターとして機能することがあるので、これらを含めることを忘れないでください。入力のサニタイズを行うために独自の関数を書かないでください。代わりに、信頼できるサードパーティのセキュリティに特化したライブラリやフレームワークの組み込みAPIを使用してください。
対象となる対策だけでなく、ネットワーク上で必要最小限の権限を持つLDAP照会アプリケーションを割り当てるなど、適切なコンピューティング・プラクティスを行うことも有効です。これにより、万が一、LDAPインジェクションが通過してしまった場合でも、その被害を軽減することができます。
LDAPインジェクションの詳細情報
さらに読みたい方は、OWASP の LDAP インジェクションに関する記事や、インジェクション防止のためのチートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
