LDAPインジェクションの深淵：プロトコル仕様の罠と「防御の境界」を再定義する
LDAP（Lightweight Directory Access Protocol）は、認証基盤やディレクトリサービスとして、今なおエンタープライズの心臓部で鼓動を続けている。しかし、その枯れたプロトコルゆえに、現代のアーキテクトが見落としがちな「泥臭い脆弱性」が存在する。それがLDAPインジェクションだ。
SQLインジェクションが「クエリの文法破壊」を主戦場とするなら、LDAPインジェクションは「フィルタリング論理のすり抜け」と「ディレクトリ階層の探索」を狙う、よりシビアなコンテキスト依存型の攻撃だ。今日は、教科書的な説明を飛び越え、この脆弱性の根本原因と、現代的なアーキテクチャにおける防御の実装について深掘りしよう。
—
1. 攻撃ベクトル：フィルタ構文のメタ文字がもたらす「論理の崩壊」
LDAPクエリは、RFC 4515で定義されるフィルタ構文に基づいている。攻撃者が狙うのは、(&(uid=USER)(userPassword=PASS)) といったクエリに対し、（ワイルドカード）や ( ) & | !
攻撃の核心：評価順序のハイジャック
例えば、ログイン処理で (&(uid=admin)(userPassword=PASS)) を生成しているコードに対し、PASS パラメータに )(uid=))(|(uid= を送り込んだらどうなるか。
生成されるクエリは (&(uid=admin)(userPassword=)(uid=))(|(uid=)) となり、パスワード認証を実質的に無効化し、クエリを常に真（True）に評価させる。
これは単なる文字列連結のミスではない。プロトコル仕様が持つ柔軟性が、そのまま攻撃の踏み台になっているという事実に目を向けなければならない。
—
2. フィルタエスケープの「正しい」実装：ライブラリを盲信しない
多くの開発者が「エスケープ関数を通せば安全」と考えがちだが、ここには落とし穴がある。エスケープは「データ」を「制御文字」として解釈させないための壁だが、コンテキストによって「どの文字をエスケープすべきか」が異なるからだ。
安全な実装例：Java (UnboundID LDAP SDK) の場合
汎用的なエスケープではなく、ライブラリが提供する正規化関数を正しく適用する。
import com.unboundid.ldap.sdk.Filter;
// ユーザー入力
String userInput = getFromRequest(“username”);
// 1. まずはユーザー入力をフィルタ構文内の「値」として適切にエスケープする
// 2. その上でFilterオブジェクトを構築する
// これにより、文字列連結による構文破壊を構造的に防止する
Filter filter = Filter.createEqualityFilter(“uid”, userInput);
// 実行時のクエリ構築はライブラリ内部で行われるため、
// 手動の文字列連結は一切行わない（これが防衛の鉄則）
SearchResult result = connection.search(“dc=example,dc=com”, SearchScope.SUB, filter);
重要な観点：
脆弱性の根本原因は「データとコード（クエリ構文）の混在」にある。パラメータ化されたクエリ（Prepared Statements）に近いアプローチを取らない限り、エスケープの漏れは必ずどこかで発生する。
—
3. 次世代の防衛アーキテクチャ：ガードレイルの設計
現代のセキュリティアーキテクチャにおいて、アプリケーション単体での防御には限界がある。特にAIを活用したプロンプトインジェクションや、高度な自動化攻撃に対しては、「防御層の多重化」が必要だ。
① 認可の分離（Authorization vs Authentication）
LDAPを単なる認証（Who are you?）に留め、認可（What can you do?）のロジックをアプリケーション層やOPA（Open Policy Agent）のようなポリシーエンジンに切り離す。LDAPへのクエリ範囲を最小限のスコープに限定することで、万が一インジェクションが成功しても、アクセス可能なディレクトリツリーを物理的に制限する。
② 生成AI時代のガードレイル設計
LLMがLDAPを操作するシステムを構築する場合、「セマンティック・ファイアウォール」を導入せよ。LLMの出力をそのままクエリにするのではなく、以下の手順を通すのが鉄則だ。
- 構造化スキーマ強制: LLMの出力をJSON等の厳密な形式で受け取り、バリデーションを行う。
- クエリ・サンドボックス: 生成されたクエリを解析し、許可された属性（例：
cn,mailのみ）以外へのアクセスがないか、正規表現または構文解析器でチェックしてからLDAPサーバーへ投げる。
—
4. 最後に：監査とインシデントハンドリングの視点
チーフホワイトハッカーとして諸君に伝えたいのは、「ログこそが最大の防衛」だということだ。LDAPの通信パケットを解析し、特定の異常な検索パターン（例えば、ワイルドカードが異常に多い、あるいは階層を深く探索するクエリ）をSIEMで検知できるようにしておけ。
LDAPインジェクションは、一度侵入を許せばディレクトリ構造全体を列挙されるリスクを孕む。これは単なるデータ漏洩ではなく、社内の組織図やシステム間の依存関係という「設計図」を渡すに等しい。
コードを書くとき、そしてインフラを設計するとき、常に自問自答してほしい。「このクエリは、攻撃者が意図的に歪めたとしても、我々の論理を破壊できないほど堅牢か？」と。
技術は進歩するが、攻撃者が突く「人間の油断」と「仕様の隙間」は変わらない。我々エンジニアがすべきことは、その隙間を技術で埋め、攻撃者に「コストに見合わない」と判断させることだ。それこそが、究極のセキュリティである。
コメント