LDAPインジェクションの深淵：プロトコルの盲点と「安全」の境界線
LDAPインジェクション。この言葉を聞いて「ああ、や()
現実のインシデント現場では、この脆弱性は単なる「認証バイパス」以上の破壊力を持つ。ディレクトリサービス（Active DirectoryやOpenLDAP）は、企業のID管理、ロールベースアクセス制御（RBAC）、さらにはインフラの心臓部だ。一度このゲートを突破されれば、攻撃者は横展開（Lateral Movement）の極めて強力な足場を確保することになる。
今日は、教科書的な「エスケープしろ」という教訓の先にある、アーキテクトが知るべき本質的な防御ロジックについて掘り下げる。
—
1. プロトコル仕様が孕む「解釈の二重性」
LDAP（RFC 4511）のフィルタ構文は、Polish表記（前置記法）に基づいている。攻撃者が狙うのは、アプリケーションが受け取った入力を、バックエンドのLDAPサーバが「検索パラメータ」としてではなく「フィルタの論理演算子」として再解釈させる隙だ。
例えば、(&(uid=USER_INPUT)(userPassword=PASS_INPUT)) というフィルタを構築する際、入力に )(uid=))(|(uid= を挿入されたとする。結果として生成されるクエリは以下のように変貌する。
(&(uid=)(uid=))(|(uid=)(userPassword=...))
論理構造が破壊され、最初の uid= が常に真（True）を返すことで、パスワード照合をスルーしてログインできてしまう。これは単なる文字列連結の問題ではない。アプリケーション層のバリデーションと、LDAPプロトコルが解釈するパケット構造の「解釈のミスマッチ」こそが根本原因だ。
2. ライブラリ依存の罠：エスケープの限界
「ライブラリの関数を使っているから大丈夫」という慢心は、CISSPとして最も警戒するポイントだ。例えば、多くの開発者が利用する LdapEscape 系の関数は、あくまで「文字列リテラル内での制御文字」を無害化するに過ぎない。
もし、ディレクトリサービス側のスキーマ設計が不適切で、dn（識別名）の構築にまで動的な入力が紛れ込んでいる場合、フィルタエスケープだけでは不十分だ。LDAPインジェクションの真の対策は、「入力を一切信用しない」のではなく「クエリ構築を完全に分離する」ことにある。
推奨される実装（静的フィルタの徹底）
動的な文字列連結は「悪」である。可能な限り、パラメータバインディングをサポートしたライブラリを選択し、物理的にクエリ構造を分離すべきだ。
// 安全な実装例: プリペアードな手法の模倣
// 実際には、LDAPライブラリが提供するプレースホルダ機能を利用する
String filter = “(&(objectClass=user)(sAMAccountName={0}))”;
Object[] params = new Object[] { userInput };
// SearchControlsとフィルタを分離して実行することで、
// インジェクションの余地を排除する
NamingEnumeration
3. 生成AI時代の新たな脅威：プロンプト注入との相乗効果
最近、我々が警戒しているのは、LLMを介したLDAPクエリ生成だ。自然言語で「特定の部署のユーザーをリストアップして」と指示した際、LLMがバックエンドで生成するLDAPクエリがインジェクションを許容する形式になっていないか？
これは新しい攻撃ベクトルだ。LLMをガードレイル（防御層）で囲う際、以下の観点を設計に組み込む必要がある。
1. 静的コード解析（SAST）との統合: 生成されたクエリが、固定されたフィルタテンプレート外へ逸脱していないかを検知するミドルウェアの導入。
2. 最小権限の原則（Least Privilege）: アプリケーションがLDAPサーバに対して持つ権限を、読み取り専用かつ特定の属性のみに絞り込む（ACLの精査）。
3. 量子耐性への備え: 将来的な暗号解読リスクに対し、LDAP over TLS (LDAPS) の暗号スイートを最新のポスト量子暗号（PQC）対応アルゴリズムへ移行できるアーキテクチャの確保。
4. チーフホワイトハッカーからの提言
あなたが現場のテックリードなら、明日から以下の監査項目を追加してほしい。
- 入力の正規化プロセス: Unicodeの正規化（Normalization）を行っているか？ 特殊文字をエスケープする前に全角文字を半角へ変換する等の処理が、かえって攻撃の隠れ蓑になっていないか。
- ログの相関分析: LDAPの「認証失敗」ログと「検索クエリの複雑度」を相関させよ。単純な失敗ではなく、フィルタの構造が異常に長いリクエストが頻発しているなら、それは攻撃の予兆だ。
- スキーマのクリーンアップ: 不要な属性を検索対象から除外せよ。攻撃者が探索できる「情報」を減らすことが、最大の防御になる。
LDAPインジェクションは、歴史の長い古典的な攻撃手法だ。しかし、システムが複雑化し、クラウドネイティブな認証基盤と深く結合した今、そのリスクはかつてないほど高まっている。
「動くから良い」という思考を捨て、「なぜこれが安全と言い切れるのか」をプロトコルのレベルまで掘り下げて証明すること。それが、我々エンジニアが守るべき最後の防壁だ。
コメント