LDAPインジェクションとは？仕組みと防止方法

LDAPインジェクションとは？

LDAPインジェクションは、適切に処理されていないユーザー入力からLightweight Directory Access Protocolのクエリを構築するWebアプリケーションを悪用する、サーバー側の攻撃です。アプリケーションが特殊文字を適切に無害化せずにLDAPクエリへ組み込むと、攻撃者はクエリを操作して認証を回避したり、機密性の高いディレクトリデータを抽出したり、LDAPツリー内のエントリを変更したりできます。

LDAPディレクトリは、企業のID基盤の中核です。ユーザー認証情報、グループメンバーシップ、アクセス制御リスト、組織構造、サービスアカウントの詳細を保存しています。LDAPインジェクション攻撃が一度成功するだけで、この情報が露出し、攻撃者に認証基盤へのアクセスを許すおそれがあります。

MITREは、この脆弱性をMITRE CWE-90：LDAPクエリで使用される特殊要素の不適切な無害化に分類しています。OWASPは、OWASP Injectionと更新後のOWASP Injectionカテゴリに分類しています。この脆弱性は SQLインジェクションと根本原因が同じですが、標的は根本的に異なり、影響がより大きくなることもあるシステムです。組織全体で誰が何にアクセスできるかを管理するディレクトリサービスが狙われます。

LDAPインジェクションの仕組みを理解するには、攻撃者が悪用するクエリ構文を知る必要があります。

LDAPインジェクションの仕組み

LDAP検索フィルターは、 LDAP構文で定義された特定の文法に従います。フィルターはポーランド記法（前置記法）を使用し、単純な認証クエリは次のようになります。

&演算子は論理積（AND）を実行します。括弧は条件をグループ化します。ワイルドカードの*は任意の値に一致します。これらのメタ文字に加え、| (OR), ! (NOT), =, ~=, >=, <=, and ()のグループ化演算子が、インジェクションの攻撃対象となります。

開発者がユーザー入力をクエリ文字列に直接連結してフィルターを構築すると、これらのメタ文字が攻撃に利用されます。ログインフォームがユーザー名を(&(uid=INPUT)(userPassword=HASH)),のようなフィルターに直接挿入する場合、攻撃者は細工したメタ文字を送信してフィルターの論理を完全に変えられます。その結果、認証の回避、ディレクトリの全エントリの取得、データの1文字ずつの抽出が可能になります。

攻撃者が使う具体的な手法は、LDAPインジェクションの種類によって異なります。

LDAPインジェクションの種類

LDAPインジェクションには複数の種類があり、それぞれアプリケーションとディレクトリのやり取りの異なる部分を標的にします。攻撃者が使う種類は、アプリケーションの動作、クエリの状況、応答から観察できる情報によって決まります。

検索フィルターへのインジェクション

脆弱なJavaコードの例を見てみましょう。

攻撃者がuser=*を送信すると、生成されるフィルターは(cn=*)となり、cn属性を持つディレクトリ内のすべてのオブジェクトに一致します。アプリケーションは単一のレコードではなく、ユーザーディレクトリ全体を返します。

認証の回避

LDAP認証フローへのインジェクションは、最も深刻な影響をもたらします。脆弱なログインフィルターの例を示します。

このフィルターは、ユーザー名として)(uid=))(|(uid=*を挿入すると回避できます。生成されるフィルターは常に真と評価され、攻撃者はLDAPツリー内の最初のユーザーとして認証されます。そのユーザーは管理者アカウントであることも少なくありません。この テストガイドでは、これをSQLインジェクションによる認証回避手法に直接相当するものとして説明しています。

ブラインドLDAPインジェクション

アプリケーションがクエリ結果を直接表示しない場合、攻撃者は応答の違いを利用してデータを抽出します。次のようなフィルター条件を挿入し、(attribute=a*), (attribute=b*)アプリケーションが結果を返すか、空のページを返すかを観察して、属性値を1文字ずつ抽出します。 Black Hatの論文では、表示情報を制限するクライアント側のフィルターでは、ブラインドインジェクション手法を防げないことが示されました。

識別名の操作

LDAPではエスケープ処理が必要な文脈が異なり、それらを混同するとインジェクションの侵入口が生じます。検索フィルターにはRFC 4515に従ったエスケープ処理が必要です(*→\2a, (→\28, )→\29)。識別名（DN）にはRFC 2253に従ったエスケープ処理が必要です(\, #, +, <, >, ,, ;, ", =)。フィールドに適さないエスケープ処理を適用すると、対策済みだと思っていても、アプリケーションに脆弱性が残ります。

これらの攻撃には、構文の問題にとどまらない共通の根本原因があります。

LDAPインジェクションの原因

LDAPインジェクションの脆弱性は、コーディング手法、ライブラリの制約、インフラの設定ミスが重なって生じます。それぞれの根本原因が、悪用につながる独立した経路を作ります。

• 文字列の直接連結。 LDAPインジェクションの脆弱性のほぼすべてで直接の原因となるのは、アプリケーション層でユーザーが制御できるデータをLDAPフィルター文字列に直接連結することです。LDAPライブラリには従来、パラメーター化されたクエリを標準でサポートする機能がなく、開発者は安全なクエリ構築のために 手動での実装に関するガイダンスに従う必要がありました。パラメーター化されたインターフェースは存在しますが、意識して採用する必要があります。
• 特殊文字の不適切な管理。 入力値を検証するアプリケーションでも、危険な文字を見落とす不完全な拒否リストを実装していることがあります。*と(をブロックしても、)やNULバイトを見落とす拒否リストには、悪用可能な抜け穴が残ります。 MITRE CWE-90では、LDAPインジェクションをこの不備から生じる脆弱性と位置付けています。つまり、インジェクションの脆弱性は、特殊文字の不適切な管理から直接生じます。
• エスケープ処理の文脈の混同。 LDAPのチートシートでは、検索フィルター用のエスケープ処理をDNフィールドに適用したり、DN用の処理を検索フィルターのフィールドに適用したりすると、文脈の選択ミスによってインジェクションの侵入口が生じると説明しています。開発者がエスケープ処理の必要性を理解していても、誤った関数を選べば、アプリケーションに脆弱性が残ります。
• 匿名バインドと未認証バインドの設定。 匿名バインドを許可する設定のLDAPサーバーでは、攻撃者はバインド認証そのものを回避できます。
• 認証におけるLDAPの広範な利用。 LDAPはエンタープライズ環境の認証基盤を担っているため、ログイン処理に対するインジェクションは、企業全体のリソースへの認証済みアクセスという重大な結果を招きます。攻撃対象領域は、アーキテクチャ上、企業全体に及びます。

これらの原因が重なると、単一のクエリの侵害をはるかに超えるリスクが生じます。

LDAPインジェクションの影響とリスク

LDAPインジェクション攻撃は、事業に複数の種類の影響を及ぼし、その深刻さは段階的に増します。

認証の回避

常に真となるフィルター条件を挿入すると、直ちに認証済みアクセスを取得できます。OpenText Enterprise ServerのCVE-2023-4501では、パスワードが正しいかどうかに関係なく、有効なユーザー名で認証が成功しました。無効なユーザー名と任意のパスワードでも成功する可能性がありました。この脆弱性は、金融サービス、保険、政府機関に導入されたエンタープライズ向けCOBOLの開発環境と実行環境に影響しました。

機密データの流出

LDAPディレクトリには、ユーザーの認証情報、パスワードハッシュ、メールアドレス、組織階層、グループ所属情報、ACL、コンピューターアカウント、 セキュリティ識別子が含まれます。 CISAの勧告では、1回のLDAPクエリで企業のディレクトリからユーザー、コンピューター、グループ、ACL、OU、GPOに関する情報を取得できた事例が記録されています。

権限昇格

インジェクションが成功すると、許可されていないクエリを実行する権限を取得し、LDAPツリー内の内容を変更できる場合があります。Parse ServerのCVE-2026-31828では、認証済みの低権限ユーザーがLDAPフィルターインジェクションを通じて、任意のアクセス制限付きグループに権限を昇格できました。

サービス拒否

CVE-2025-12764 (pgAdmin) は、LDAPインジェクションを悪用してDC/LDAPサーバーとクライアントに異常な量のデータを処理させ、ディレクトリ基盤にサービス拒否を引き起こし、認証障害を連鎖させる手法を実証しました。

ラテラルムーブメントの足がかり

LDAPによる情報収集は、Active Directoryの偵察に利用されます。CISAのレッドチーム勧告では、LDAPデータからユーザー、コンピューター、グループ、ACL、OU、GPOを把握でき、これらすべてが ラテラルムーブメントの計画に使われると報告されています。評価対象の企業では、この活動をまったく可視化できていませんでした。

OWASPは OWASPフレームワークで、インジェクションの悪用の容易さを3（容易）、技術的影響を3（深刻）と評価しています。LDAPインジェクションはコンプライアンスにも直接影響します。 PCI DSS 6.5.1では、SQLインジェクションやXPathインジェクションと並び、LDAPインジェクションを評価すべき対象として明示しています。

影響を理解すれば、防御の優先順位を決められます。同時に、攻撃者がこうした欠陥をどう発見し、悪用するかも正確に把握する必要があります。

攻撃者によるLDAPインジェクションの悪用方法

攻撃者は体系的な手順でLDAPインジェクションの脆弱性を発見・悪用し、偵察から認証情報の全面的な抽出へと進みます。

ステップ1：LDAPと連携する入口を特定する

攻撃者は、LDAPバックエンドに問い合わせる可能性が高いアプリケーション機能を特定します。 SANSのLDAPブログによると、LDAPはディレクトリデータベース内のオブジェクトの管理、認証、検索に使用できます。ログインフォーム、ユーザー検索ページ、パスワードリセットのフロー、社内ディレクトリ検索、VPNゲートウェイのポータルは、いずれも攻撃対象の候補です。

ステップ2：インジェクション可能な箇所を探る

では、テスターが(, |, &, *などの文字を挿入し、差分レスポンスを確認することを推奨しています。エラーメッセージ、空の結果セット、アプリケーション挙動の変化は、脆弱なパラメータの存在を示します。では、テスターに文字 (, |, &, * を入力し、応答の違いを確認するよう指示しています。エラーメッセージ、空の結果セット、アプリケーションの動作の変化は、脆弱なパラメーターの存在を裏付けます。

ステップ3：フィルターの構造を推測する

攻撃者はソースコードがなくても、ファジングによってLDAPフィルターの構造を推測します。SANSは次のように述べています。「ペネトレーションテスト中に、こうしたステートメントを確認できるソースコードが手元にあるとは考えにくいでしょう。その場合は、ファジングと偵察が必要になることがあります」

ステップ4：インジェクションのペイロードを作成する

一般的なペイロードは次のとおりです。

• ワイルドカードインジェクション (*) を使い、ディレクトリの全エントリを取得するでディレクトリエントリ全体を取得
• 常に真となるフィルター ()(uid=))(|(uid=*)を使い、認証を回避する
• ORを使った属性インジェクション ()(department=it)(|(cn=) を使い、複数の属性から認証情報を収集する
• nullオブジェクトクラスによる終端処理 (*)(objectClass=*))(& (objectClass=void)を使い、ブラインド抽出に利用できる信頼性の高い真偽判定手段を確立する

使用するペイロードは、攻撃者が偵察中に推測したフィルターの構造によって異なります。

ステップ5：攻撃チェーンを通じて侵害を拡大する

OWASPとMITRE ATT&CKの資料で報告されている典型的な攻撃チェーンは、次のように進みます。

1. 常に真となるフィルターを使ってログインを回避する
2. ORを使ったインジェクションでドメインの認証情報を抽出する
3. ldapmodifyを使ってドメインアカウントを作成する（ATT&CK T1136.002）
4. NTDS.ditをダンプし、オフラインで認証情報を解析する (ATT&CK T1003.003)

ブラインドLDAPインジェクションでは、攻撃者が別の攻撃経路をたどることもできます。(attribute=*)による試行でスキーマ属性を列挙し、パスワードハッシュ、グループメンバーシップ、セキュリティ識別子などの値を1文字ずつ抽出します。

こうした悪用手法は、幅広い組織やアプリケーションに影響します。

LDAPインジェクションの影響を受けるのは？

LDAPを基盤とする認証を利用する組織はすべて、この脆弱性に構造的にさらされています。OWASPは、インジェクションの脆弱性は「特に レガシーコードで非常に多く見られる」と指摘しています。

特に影響を受けやすいアプリケーションは次のとおりです。

• LDAPを基盤とする認証を利用するWebアプリケーション（ログインポータル、SSOシステム）
• 文字列を連結してLDAPクエリを構築するレガシーの企業向けアプリケーション
• セルフサービス型のパスワードリセットポータルと従業員ディレクトリポータル
• VPNゲートウェイとリモートアクセスポータル
• 産業用制御システムの管理プラットフォーム
• デスクトップアプリケーション（OWASP Desktop App Security Top 10では、LDAPインジェクションを DA1 インジェクションに分類）

リスクが集中する業界は次のとおりです。

• 医療: LDAPを基盤とする電子健康記録（EHR）や臨床システムは、未修正の脆弱性についてHIPAAに基づく措置の対象となります。HHSは HHSの侵害データにおいて、2018年から2022年までの大規模な侵害を記録しています。
• 金融サービス: この業界では、IDに関連する企業システムに対するインジェクションが、引き続き攻撃対象となっています。
• 政府機関と重要インフラ: CISAは、政府環境やICSを利用するエネルギー分野のプラットフォームで、実際に悪用されていることを記録しています。
• ソフトウェア・テクノロジー: オープンソースのバックエンド、データベースツール、開発プラットフォームでは、LDAPインジェクションに関する新たなCVEが報告され続けています。

LDAPインジェクションは、企業のCOBOL環境、データベース管理ツール、エネルギー分野のプラットフォーム、オープンソースのバックエンドなど、幅広いソフトウェアに影響します。これは仮定上のリスクではありません。近年のインシデントが裏付けています。

LDAPインジェクションの実例

以下の事例は、政府機関のネットワーク、企業向けプラットフォーム、オープンソースツールでLDAPインジェクションがどのように起こるかを示しています。

CISAレッドチーム: LDAP通信をまったく監視していなかった企業（2024年）

では、評価対象エンタープライズが「異常なLDAPトラフィックの監視を行っていなかった」と記録されています。チームはLDAPSをクエリし、ユーザー、コンピューター、グループ、ACL、OU、GPOの情報を収集しました。CISAは、LinuxドメインホストからLDAPをクエリする非特権ユーザーの行為が「ネットワーク防御担当者に警告を与えるべきだった」と明記しています。では、評価対象の企業が「異常なLDAPトラフィックを監視していなかった」ことが判明しました。チームはLDAPSにクエリを送信し、ユーザー、コンピューター、グループ、ACL、OU、GPOに関する情報を収集しました。CISAは、Linuxのドメインホストから特権を持たないユーザーがLDAPにクエリを送信した時点で、「ネットワークの防御担当者にアラートが届くべきだった」と明言しています。

OpenText Enterprise Server: 認証の完全な回避（CVE-2023-4501）

この脆弱性により、有効なユーザー名であればパスワードに関係なく認証に成功し、無効なユーザー名でも成功する場合がありました。金融サービス、保険、政府機関のメインフレーム連携に導入された、企業向けCOBOLの開発環境と実行環境が影響を受けました。

Ivanti EPMM: 脅威アクターによるLDAP認証情報のダンプ（2025年）

2025年5月に概念実証が公開された後、脅威アクターはIvanti EPMMサーバーにアクセスし、 LDAP認証情報をダンプしました。CISAは、原因となった脆弱性を2025年5月19日にKEVカタログへ追加しました。

Redash: パスワードスプレー攻撃を可能にするLDAPインジェクション（CVE-2020-36144）

GitHub Security Labは、RedashのLDAP認証におけるメールアドレス欄が、エスケープ処理なしでLDAPフィルターのクエリ文字列を構築していたと報告しました。これにより、認証されていない攻撃者が1回のリクエストで全ユーザーのパスワードに対して総当たり攻撃を実行できました。

これらのインシデントは、数十年にわたるLDAPのセキュリティ課題を物語っています。

LDAPインジェクションの年表と歴史

LDAPインジェクションは20年以上前から知られる脆弱性の一種です。1990年代後半から現在まで、正式な分類とCVEの公開が続いています。

• プロトコルの起源。 X.500 Directory Access Protocol (DAP)はITU-Tによって開発されました。LDAP v1はRFC 1487、v2はRFC 1777、v3はRFC 2251で登場しました。現在も企業で使用されているのはv3です。
• 最初に文書化された問題。 CVE-1999-0895では、Checkpoint FireWall-1 V4.0における初期のLDAP認証のセキュリティ問題が文書化されました。
• 正式な分類。 OWASPはLDAPインジェクションを独立した攻撃クラスとして正式に文書化しました。2007年のOWASP Top 10では、A2「インジェクションの欠陥」に分類されました。
• ブラインドインジェクションの研究。 AlonsoらはBlack Hat Europeで体系的な ブラインドLDAP研究を発表し、1文字ずつデータを抽出する手法を実証しました。
• OWASPにおける優先度のピーク。 OWASP Top 10 2017では、LDAPインジェクションを明示したうえで、インジェクションをWebアプリケーションの最大のリスクであるA1に位置付けました。
• ICSへの攻撃。 CVE-2018-14805 (ABB eSOMS)により、LDAPインジェクションの影響はエネルギー分野のICSにも及びました。
• 企業向けプラットフォームへの攻撃。 ForgeRock OpenAM、OpenLDAP、OpenText Enterprise Serverの事例は、企業への影響が続いていることを示しました。
• 最近の脆弱性開示。 近年公開された新たなCVEは、Apache Druid、WatchGuard Fireware、WeKan、Parse Server、Dell PowerMax、pgAdminに影響します。

新たなCVEの報告は続いており、継続的な監視が実務上必要です。

LDAPインジェクションの検知方法

アプリケーション、ディレクトリ、ネットワークの各層で多層的に監視する必要があります。

アプリケーション層の兆候

ユーザー入力フィールドでLDAPメタ文字を監視します。対象は*, (, ), \や、認証・検索パラメーター内のNULバイトです。全ディレクトリエントリを返すワイルドカードインジェクションを示唆する、異常に大量のLDAP検索結果に注意してください。不正な形式のクエリの直後に認証が成功した場合は、認証回避の兆候です。

LDAPサーバー層の兆候

フィルターグループの操作を示す)(や|(を含むフィルター構造を確認します。(objectClass=*)または(cn=*)を使って全エントリを返すクエリは、ワイルドカードによる列挙を示唆します。匿名バインドに続く広範な検索操作は、未認証の偵察行為を示します。

SIEMとイベントログの監視

Active Directory環境では、次の2つのWindowsイベントIDが重要です。

• イベントID 4662： ADオブジェクトに対して実行された操作です。Write Property、Control Access、DELETE、WRITE_DAC、WRITE_OWNERの操作を監視します。
• イベントID 1644： 負荷が高い、または非効率なLDAPクエリです。インジェクションの試行で頻繁に発生します。

次のによれば、「ログ内の異常な検索フィルタを探してください。攻撃者はユーザー、グループ、コンピューターを列挙するために特定のフィルタをよく使用します。」によると、「ログ内の通常とは異なる検索フィルターを探してください。攻撃者は特定のフィルターを使い、ユーザー、グループ、コンピューターを列挙することがよくあります。」

振る舞いの相関パターン

複数のデータソースを照合して、インジェクション攻撃の一連の活動を見つけます。

• 単一の送信元IPからの大量のLDAPクエリ（インジェクションツールの使用）
• 属性の順次列挙： uid=a*, uid=b* （ブラインドインジェクションによる抽出）
• パスワード認証の失敗直後にログイン成功（認証回避の確認）
• 権限のないLinuxドメインホストによる大量のLDAPクエリ（CISAが未検知の事例として記録したパターンそのもの）

これらの兆候を複数のデータソースにわたって照合することで、単一の兆候だけでは見えない進行中のインジェクション攻撃をより明確に把握できます。

WAFレベルの監視

OWASP ModSecurity Core Rule Setには、Rule ID 921200が REQUEST-921-PROTOCOL-ATTACK.conf, に含まれます。このルールは重大度CRITICAL、Paranoia Level 1（デフォルトで有効）でLDAPインジェクションを対象とします。リクエストのCookie、引数名、引数値、XML本文を検査し、LDAPフィルターのメタ文字パターンを検出します.

不審な活動の発見だけでは不十分です。適切な防止策が必要です.

LDAPインジェクションを防ぐ方法

防止には、コード、設定、インフラストラクチャの各層にわたる多層防御が必要です.

コードレベルの防御

• パラメーター化されたLDAPクエリを使用します. 最も効果的なのは、ユーザー入力をフィルター文字列に連結せず、パラメーターとして渡す方法です:

• コンテキストに応じたエスケープを適用します. LDAPのコンテキストに適したエスケープ関数を使用します。検索フィルター（RFC 4515）では、*→\2a, (→\28, )→\29, \→\5c, NUL→\00. 識別名（RFC 2253）では、\, #, +, <, >, ,, ;, ", =, および先頭と末尾のスペースをエスケープします.

言語別の実装例は次のとおりです:

• 許可リストによる検証を実装します. LDAP操作の前に、入力が想定されるパターンに一致するか検証します。そのフィールドで想定されないメタ文字を含む入力は拒否します。検証前に入力を正規化（Unicode正規化）します。詳細は OWASPチートシート.

インフラストラクチャの強化

• 匿名バインドと未認証バインドを無効にします. この対策だけで、複数の重大な脆弱性の根本原因を排除できます.
• LDAPS（ポート636）を使用します. NIST SP 1800-16に従い、平文のLDAP（ポート389）を無効にします。参照: NIST SP 1800-16.
• 最小権限のACLを適用します LDAPバインド用サービスアカウントに対して. 必要な操作とディレクトリサブツリーのみに権限を制限します.
• LDAPインフラストラクチャを分離します 一般のネットワークアクセスから分離します。参照: NIST SP 1800-18B.

これらの制御により、LDAPインフラストラクチャに到達した攻撃者が利用できる攻撃対象領域を縮小します。

CI/CDパイプラインへの統合

開発パイプラインに静的解析（SAST）と動的解析（DAST）を組み込みます。この OWASP Top 10では、SAST、DAST、IASTツールを使用して インジェクションの欠陥を本番環境へのデプロイ前に特定することを推奨しています。Semgrepの汚染解析モードでは、LDAPクエリの構築を対象とするカスタムルールを使用し、サニタイズされていない信頼できない入力を、入力元から処理先まで追跡できます。

こうした防止策は、適切なツールと組み合わせることで最も効果を発揮します。

検出と防止のためのツール

LDAPインジェクションを効果的に防ぐには、スキャン、監視、実行時保護の各ツールを組み合わせる必要があります。

• OWASP ZAPでは、 ZAP Alert 40015（CWE-90、WASC-29）を通じてLDAPインジェクションのアクティブスキャンを実行できます。ZAP MarketplaceのAlphaスキャンルールからインストールし、LDAPと連携するアプリケーション向けに、技術ターゲット設定へProtocol / LDAPを追加します。
• OWASP ModSecurity CRSは、WAF-レベルの保護を CRS Rule 921200によって提供します。このルールはデフォルトでParanoia Level 1で実行され、Cookie、引数、XMLペイロードにLDAPフィルターの操作を示すシグネチャがないか検査します。 CRS Issue 276のCRS回帰テスト用ペイロードは、WAFの検証にすぐ使えるファジング用ワードリストになります。
• Semgrepは、信頼できないデータを 入力元からLDAPクエリの処理先まで追跡するmode: taintルールによって静的汚染解析を行い、コードが本番環境に到達する前にインジェクションの経路を検出します。
• SIEMプラットフォームでは、カスタムの識別ルールを使用してWindows Event IDs 4662と1644を監視し、異常なLDAPクエリパターンを関連付け、属性の連続的な列挙や権限のないホストからの大量のクエリといった行動指標についてアラートを出せます。

これらのツールは問題の各層に個別に対処します。プラットフォームによるアプローチは、それらを結び付けます。

組織全体のアイデンティティリスクを軽減

Active DirectoryとEntra IDの総合的なソリューションにより、リアルタイムで攻撃を検知し、対応します。

デモを見る

関連する脆弱性

いくつかの脆弱性の種類は、LDAPインジェクションと同じパターンを共有します。

• SQLインジェクション（CWE-89）： 最も近い類例です。どちらもクエリ言語でサニタイズされていない入力を悪用し、類似した手法で認証を回避できます。ただし、構文と対象システムは大きく異なります。
• OSコマンドインジェクション（CWE-78）： MITREによると、CWE-90と同じSoftware Fault Pattern（SFP24、「コマンドへの汚染された入力」）に属します。ディレクトリサービスではなく、ホストのオペレーティングシステムを標的にします。
• XPathインジェクション（CWE-643）：  OWASPのLDAPテストでは、XMLベースのデータストアを標的とする類似の認証回避手法として、XPathインジェクションとLDAPインジェクションを明示的に同じグループに分類しています。
• 特殊要素の不適切な無害化（CWE-77）： MITREの階層では、CWE-90の上位にあたる弱点です。あらゆる種類のインジェクションは、インタープリターにとって意味を持つ文字を無害化できないという、この一般的な問題に由来します。
• 出力の不適切なエンコードまたはエスケープ（CWE-116）： エスケープの失敗からインジェクションに至る直接的な連鎖を示します。CVE-2021-41232は、Goアプリケーションでのエスケープの失敗がLDAPインジェクションを直接引き起こした、CWE-116 → CWE-90の連鎖を実証しています。
• 不適切な入力検証（CWE-20）： アプリケーションがLDAPクエリを構築する前に入力形式を検証しない場合の根本原因です。

これらの関連する弱点を確認することで、LDAP固有のコード経路だけでなく、コードベース全体に同じ防御原則を適用できます。

関連するCVE

まとめ

LDAPインジェクションでは、攻撃者が信頼できない入力を利用して、認証とアクセスに不可欠なディレクトリシステムを操作します。リスクは1つのクエリやアプリケーションにとどまりません。 

クエリを安全に構築し、適切な文脈で値をエスケープし、バインド権限を制限してLDAPの動作を綿密に監視することで、攻撃にさらされる範囲と攻撃者の活動余地を減らせます。