LDAPインジェクション：なぜ今も「盲点」になり続けるのか
現場で長年インシデントを見てきたが、SQLインジェクションは撲滅の兆しが見えても、LDAPインジェクションは未だに「あ、そこ盲点だった」という顔で修正依頼が飛んでくる。
LDAP（Lightweight Directory Access Protocol）は、Active DirectoryやOpenLDAPなど、認証基盤の心臓部で動いていることが多い。もしここを突破されたら、単なるデータ漏洩では済まない。社内のディレクトリ構造が丸裸になり、権限昇格や横展開（Lateral Movement）の踏み台にされる。今回は、この「見落とされがちな脆弱性」の急所と、確実に防ぐための武装術を叩き込む。
—
1. 攻撃者が狙う「クエリの文法破壊」
LDAPインジェクションの本質は、ユーザー入力を適切にサニタイズせず、クエリの論理構造を意図的に書き換えることにある。
例えば、ユーザーのIDを検索する以下のようなクエリを想定してほしい。
(&(uid=USER_INPUT)(objectClass=person))
攻撃者は USER_INPUT に )(uid= を流し込む。するとクエリはこう変化する。
(&(uid=)(uid=)(objectClass=person))
これだけで、すべてのユーザーがマッチしてしまう。さらに悪質なのは )(|(uid= を送り込み、認証バイパスを狙うケースだ。LDAPのフィルタ構文には「ワイルドカード」や「論理演算子」が含まれるため、SQL以上に構造が崩れやすい。
—
2. 現場で使えるセキュア実装術
一番やってはいけないのは、「特定の文字を置換する」というブラックリスト方式のフィルタリングだ。攻撃者は常にその網を潜るエンコーディング手法を探している。
鉄則：ライブラリが提供するエスケープ関数を「利用する」こと。
自作関数はバグの元だ。各言語で信頼されているライブラリの作法を守れ。
【Python】python-ldap を使った安全な実装
Pythonの場合、ldap.filter.filter_format を使うのが正解だ。フォーマット文字列を使うことで、ライブラリ側が自動的にエスケープ処理を完結させてくれる。
import ldap.filter
def secure_ldap_query(user_id):
# ユーザー入力を安全にフォーマットする
# %s の部分に値が安全にエスケープされて挿入される
search_filter = ldap.filter.filter_format(‘(&(uid=%s)(objectClass=person))’, [user_id])
# ここでLDAPコネクションに対し検索を実行する
# result = ldap_conn.search_s(base_dn, ldap.SCOPE_SUBTREE, search_filter)
return search_filter
テスト：悪意ある入力でも構造は破壊されない
print(secure_ldap_query(“)(uid=”))
出力結果: (&(uid=\2a\29\28uid=\2a)(objectClass=person))
【PHP】LdapRecord / 標準関数での実装
PHPの場合、ldap_escape 関数を必ず使うこと。フラグには LDAP_ESCAPE_FILTER を指定するのが肝だ。
—
3. インフラ層での防御（多層防御の極意）
コードレベルで防ぐのが基本だが、万が一の漏れに備えてインフラ側でも絞り込む。
- WAFの活用: AWS WAFやCloud Armor等には、LDAPインジェクションパターンを検知するマネージドルールがある。これを有効化し、
,(,),&,| - 最小権限の原則（IAM/ACL）: アプリが使用するLDAPバインド用アカウントは、「検索しかできない」かつ「特定のOU（Organizational Unit）しか見られない」ようにディレクトリ側の権限を絞れ。管理者権限のサービスアカウントでアプリを動かすなど、論外だ。
—
最後に：セキュリティは「作法」である
LDAPインジェクションが怖くないのは、防御の手順が決まっているからだ。
1. 信頼できない入力をそのままクエリに結合しない
2. 必ずライブラリ標準の「エスケープ関数」を通す
3. バインド用アカウントには必要最小限の権限しか与えない
この3つを守るだけで、君の書くコードの堅牢性は劇的に変わる。セキュリティを「後付けの苦痛」にせず、開発プロセスの一部（当たり前の作法）として組み込んでくれ。
もし実装中に「これ本当に安全か？」と迷ったら、いつでも相談してほしい。現場の泥臭い経験が、君のコードを守る盾になるはずだ。
コメント