LDAPインジェクションの深淵：プロトコル構造に潜む「論理の脱獄」をどう封じ込めるか
多くのエンジニアがSQLインジェクションには敏感だが、LDAPインジェクションに対しては「古い技術」「社内LANの中だから安全」という甘い認識でいる。これは致命的な誤りだ。ディレクトリサービスは、アイデンティティ管理の心臓部であり、ここが突破されることは、組織の全権限を奪取されるのと同義である。
今日は、表層的な対策の先にある、LDAPプロトコルそのものの挙動と、現代的なアーキテクチャにおける防御の「解」について、泥臭い現場の視点から紐解いていく。
—
1. LDAPインジェクションのメカニズム：パケットの裏側で起きていること
LDAPはRFC 4511で定義されたバイナリプロトコルだが、その検索フィルタ（Filter）は文字列ベースの構文をとる。これが諸悪の根源だ。
攻撃者が狙うのは、(&(uid=USER_INPUT)(userPassword=PASS_INPUT)) というフィルタの生成過程における「論理の断絶」である。例えば、USER_INPUT に admin)(|(uid= を挿入すると、フィルタは以下のように変貌する。
(&(uid=admin)(|(uid=)(userPassword=PASS_INPUT))
ここで重要なのは、LDAPサーバがこれをパケットとして受け取った際、パーサーがいかにして「クエリの境界」を解釈するかという点だ。論理演算子 &（AND）や |（OR）は、パケットのペイロード内で構造を動的に書き換える「メタ文字」として機能する。これを許すということは、攻撃者にクエリの構造そのものを再設計する権限を与えているに等しい。
2. 脆弱性の根本原因：ライブラリの抽象化がもたらす「盲点」
多くの開発者が陥る罠は、言語が提供するLDAPライブラリが「入力値のサニタイズを自動で行ってくれる」という幻想を抱くことだ。しかし、多くのレガシーなSDKは、フィルタ構築において単なる文字列連結を許容している。
不適切な実装例（Node.jsの例）
// 危険：文字列連結によるフィルタ構築
const filter = ‘(&(uid=’ + req.body.username + ‘)(objectClass=user))’;
// 攻撃者が ‘)(uid=))(|(uid=’ を入力すると構造が完全に破壊される
この脆弱性は、メモリ上でのクエリ構築フェーズにおいて、型安全性が担保されていないことに起因する。低レイヤで見れば、アプリケーションのメモリ空間内で「本来意図していなかったデータ」が「構文の一部」としてトークナイズされるプロセスそのものがバグだと言える。
3. 防御のアーキテクチャ：ガードレイルとしての「構造的分離」
我々のようなアーキテクトが目指すべきは、サニタイズという名の「いたちごっこ」ではなく、構造の分離である。
推奨される実装：パラメータ化されたフィルタの利用
現代的なLDAPライブラリ（例: ldapjs の適切なラッパーや、Javaの UnboundID LDAP SDK）は、SQLのプリペアドステートメントと同様のフィルタ生成メカニズムを提供している。
// 安全な例：UnboundID LDAP SDKを使用
Filter filter = Filter.createANDFilter(
Filter.createEqualityFilter(“uid”, username), // ライブラリが適切にエスケープ処理を行う
Filter.createEqualityFilter(“objectClass”, “user”)
);
このコードの背景では、特殊文字（, (, ), \, NUL）が適切にバックスラッシュ（\xx
4. チーフホワイトハッカーの視点：次世代の脅威への備え
今後、我々が直面するのは、AIが自動生成する高度なプロンプトインジェクションと、LDAPの脆弱性を組み合わせた攻撃だ。
- ガードレイルとしてのLLM: アプリケーションレイヤの前段にLLMベースのフィルタを置く場合、そのプロンプト自体がインジェクションされるリスクがある。LDAPクエリへ渡す前に、必ずハードコードされた静的なバリデーターを通し、「論理構造が期待通りか」を検証する層を設けること。
- 耐量子暗号への移行: LDAP/S（LDAP over TLS）の通信を盗聴され、内部のディレクトリ構造を把握されるリスクに対し、将来的にはハイブリッド暗号方式への移行をロードマップに組み込む必要がある。通信路が破られれば、インジェクションの成功確率は飛躍的に高まるからだ。
結論：監査の観点から
セキュリティアーキテクトとして、コードレビュー時に問うべきは一つ。「この入力値は、クエリのパーサーにどう解釈されるか？」だ。
1. 文字列連結を禁止する: コーディング規約で文字列によるフィルタ生成を禁止し、Linterで検知すること。
2. ホワイトリスト検証: 入力値が期待される正規表現（例: 英数字のみ）に合致しているか、LDAPへ投げる直前に厳格にチェックすること。
3. 最小権限の原則: アプリケーションがバインドするLDAPアカウントは、検索のみの権限に限定し、決して書き込み権限を与えてはならない。
技術的な深淵を覗き込むことは、攻撃者の視点を手にすることと同義だ。防御は常に、攻撃者の想像力を上回る「構造的な壁」を構築することから始まる。理論武装を怠るな。コードは嘘をつかないが、入力は常に裏切るものだと心得ておけ。
コメント