LDAPインジェクションとは？仕組み・被害事例・対策をわかりやすく解説

ActiveDirectoryを使っている企業でも、「LDAPインジェクション」という言葉を聞いたことがない情シス担当者は多いのではないでしょうか。

SQLインジェクションはよく知られていますが、同じ「インジェクション攻撃」の仲間であるLDAPインジェクションは、見落とされがちなWebアプリケーションの脆弱性です。特にActive Directoryと連携した社内システムや、LDAP認証を使うWebアプリを運用している環境では、攻撃者に認証を迂回される深刻なリスクになります。

この記事では、LDAPインジェクションの仕組み・被害の実態・具体的な対策について、現場で使えるレベルで解説します。

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

LDAP（Lightweight Directory Access Protocol）とは、ユーザー情報やアクセス権限を管理する「ディレクトリサービス」と通信するためのプロトコルです。Active DirectoryやOpenLDAPがその代表例で、企業の社内システムで広く使われています。

LDAPインジェクションとは、WebアプリケーションがユーザーからのLDAP検索クエリを適切にサニタイズ（無害化）しないまま使用した場合に発生する脆弱性です。攻撃者は悪意ある文字列を入力欄に混入させることで、LDAP検索条件を操作し、認証の迂回や情報の不正取得を行います。

OWASP Top 10では「A03: Injection」のカテゴリに分類されており、SQLインジェクションと並ぶ危険度の高い攻撃手法として位置づけられています。

なぜ今、LDAPインジェクションが重要なのか

・Active Directory連携システムの普及: 社内ポータル・VPNログイン・グループウェアなど、LDAPをバックエンドに使う認証システムは企業内に広く普及しています。
・SQLほど対策の認知度が低い: SQLインジェクション対策には気を配っていても、LDAPのインジェクションリスクは見落とされることが多い傾向があります。
・認証バイパスに直結: 攻撃が成功すれば、管理者アカウントを含む任意のユーザーとして認証される可能性があります。
・内部情報の大量漏洩: ディレクトリには氏名・メールアドレス・組織情報・グループメンバー情報が集約されており、攻撃されると一度に大量の内部情報が流出します。

LDAPインジェクションの仕組み（攻撃者の視点）

LDAPの検索フィルターは `(属性=値)` という書式で表現されます。WebアプリがLDAP認証を実装する際、ユーザーが入力したIDとパスワードを組み合わせた検索フィルターを動的に生成することがあります。

# 正常時: ユーザーが「alice」と「password123」を入力した場合のフィルター（概念）
(&(uid=alice)(userPassword=password123))

# 攻撃時: ユーザー名欄に「alice)(|(uid=*」を入力した場合
# フィルターが以下のように変形する
(&(uid=alice)(|(uid=*)(userPassword=dummy))
# ↑ uid=* の条件が成立するためどのユーザーにもマッチしてしまう

# 攻撃者が入力するもう一つの典型例（パスワード欄への入力）
# パスワード欄: *)(uid=*))（%00
# これにより NUL文字以降の条件が無視されるケースがある

上記のように、攻撃者がLDAPの特殊文字（`(` `)` `*` `\` など）を含む文字列を入力すると、本来の検索フィルターの構造が崩れてしまいます。結果として、パスワードを知らなくても「該当ユーザーが存在する」という条件が成立し、認証が通過してしまうのです。

攻撃パターン1: 認証バイパス

ログインフォームへの不正な入力によってLDAPフィルターを改ざんし、正規のパスワードなしに認証を突破します。管理者アカウントへのバイパスが成功すれば、システム全体を掌握されるリスクがあります。

攻撃パターン2: ブラインドLDAPインジェクション

アプリケーションがエラーメッセージを表示しない場合でも、「認証成功」「認証失敗」という応答の違いを利用して、ディレクトリ内のユーザー名・メールアドレス・グループ情報などを少しずつ推測・取得できます。NoSQLインジェクションと同様のブラインド手法であり、表面上はエラーが出なくても情報が漏洩するため検知が困難です。

攻撃パターン3: ディレクトリ情報の一括取得

LDAPのワイルドカード `*` を悪用して、本来は参照を許可されていない組織情報・グループ構成・アカウント一覧を取得します。取得した情報は後続の標的型攻撃（スピアフィッシングなど）に悪用されます。

被害を受けやすい環境

LDAPインジェクションのリスクが特に高いのは、以下のような環境です。

・Active Directory連携のWebアプリ: 社内ポータル・グループウェア・ITSMツールなど、LDAPでシングルサインオンを実現しているシステムは特に注意が必要です。
・古いバージョンのOSS認証モジュール: WordPressのLDAP認証プラグインや、古いPHP/Java製Webアプリでは、LDAPエスケープが不完全な実装が残っているケースがあります。
・自社開発のWebシステム: 開発者がLDAPインジェクションのリスクを認識せず、入力値の検証を省略したコードになっていることがあります。SQLインジェクション対策の知識はあっても、LDAPのエスケープ手順は知らないエンジニアも少なくありません。

具体的な防御手順

1. 入力値のLDAPエスケープ（最重要）

LDAPインジェクションへの最も根本的な対策は、LDAPの特殊文字を適切にエスケープすることです。以下の文字はLDAPフィルターで特別な意味を持つため、ユーザー入力に含まれていた場合は必ずエスケープが必要です。

# エスケープが必要なLDAP特殊文字
(  → \28
)  → \29
*  → \2a
\  → \5c
/  → \2f
NUL → \00

# PHPの例: ldap_escape() 関数（PHP 5.6以降）を必ず使う
$safe_uid = ldap_escape($user_input, "", LDAP_ESCAPE_FILTER);
$filter = "(&(uid=" . $safe_uid . ")(objectClass=person))";

# Javaの例: Apache Directory APIのLdapUtils等を使用
# String safeDN = LdapUtils.escapeSearchFilter(userInput);

重要なのは「自前でエスケープを実装しない」ことです。特殊文字の抜け漏れが生じやすく、バイパスのリスクが残ります。言語やフレームワークが提供する公式のLDAPエスケープ関数を必ず使用してください。

2. ホワイトリスト型の入力バリデーション

ユーザー名・メールアドレスなど、入力形式が決まっている項目には、正規表現でのホワイトリスト検証を組み合わせます。エスケープとの二重防御として有効です。

・英数字のみ許可する場合: `^[a-zA-Z0-9_\-.]+$` の形式でチェックする
・メールアドレス: 標準的なメールアドレスバリデーション関数を使用する
・最大文字数の制限: 異常に長い入力を拒否し、バッファや処理への負荷を防ぐ

3. バインドアカウントの最小権限化

WebアプリがActive Directoryに接続する際に使うサービスアカウント（バインドDN）の権限を最小限に絞ります。攻撃が成功しても被害範囲を限定できます。

・読み取り専用権限のみ付与: ログイン検索に使うアカウントには、書き込み・削除権限を持たせない
・アクセス範囲をOUで制限: アプリが参照できるディレクトリのOU（組織単位）を、必要なものだけに絞り込む
・専用サービスアカウントを使用: ドメイン管理者アカウントをバインドDNとして使用しない

4. LDAPS / STARTTLSによる暗号化通信の強制

LDAP通信が平文（ポート389）で行われている場合、通信経路上での盗聴リスクがあります。LDAPS（ポート636）またはSTARTTLSによる暗号化通信を強制し、認証情報が平文で流れる状態を解消します。

5. エラー情報の非開示

「ユーザーが見つかりません」「パスワードが違います」といった詳細なエラーメッセージを外部に表示すると、攻撃者に情報を与えてしまいます。エラーは「認証に失敗しました」のような汎用的なメッセージに統一し、詳細はサーバーログにのみ記録します。

中小企業でも今日からできること

大規模なシステム改修が難しい環境でも、以下の対策から着手できます。

・使用フレームワークのバージョン確認: JavaのSpring Security、PHPのSymfonyなどのメジャーフレームワークはLDAPエスケープを内蔵しています。古いバージョンを使っていないか確認し、サポート中の安定版にアップデートします。
・バインドアカウントの権限見直し: Active Directory管理コンソールを開いて、Webアプリ用サービスアカウントのグループ・権限を確認するだけなら数分でできます。管理者グループに入っている場合は読み取り専用グループに変更します。
・WAFのLDAPルールを確認: WAF（Webアプリケーションファイアウォール）を導入済みの場合、LDAPインジェクション対策ルールが有効になっているか設定画面で確認します。
・脆弱性スキャンを実施: OWASPのZAP（Zed Attack Proxy）などの無料ツールで、ログインフォームに対してインジェクション攻撃のテストを行えます。自社ツールで手軽に確認できます。

よくある誤解と注意点

【誤解1】「社内システムだから外から攻撃されない」
LDAPインジェクションは内部ネットワークからの攻撃にも使われます。VPNやリモートアクセスの普及により「社内限定」の前提が崩れているシステムも多く、外部公開していない社内ポータルでも対策は必要です。

【誤解2】「LDAPは使っていない」
Active Directoryを使っているシステムは内部的にLDAPプロトコルを使用しています。「LDAP認証を自分で実装していない」場合でも、使用しているミドルウェアや認証ライブラリがLDAPを使っている可能性があります。まずは使用技術を棚卸しすることが大切です。

【誤解3】「エスケープだけで万全」
エスケープは基本対策ですが、それだけでは不十分です。最小権限化・入力バリデーション・エラー情報の管理・通信の暗号化を組み合わせた多層防御が求められます。

【注意】不正アクセスの試行は法律違反
この記事は防御目的での学習を目的としています。許可なく他者のシステムに対してLDAPインジェクション攻撃を試みることは、不正アクセス禁止法（不正アクセス行為の禁止等に関する法律）に抵触します。詳細は法律の専門家にご確認ください。

本記事のまとめ

LDAPインジェクションはSQLインジェクションに比べて知名度が低い分、対策が後回しになりがちです。しかしActive Directory連携システムを持つ企業にとっては、認証バイパスというきわめて深刻な被害に直結するリスクです。

まずはバインドアカウントの権限確認から始め、エスケープ処理の実装確認・WAFルールの確認へと段階的に対策を強化してください。Webアプリケーションの脆弱性全体を体系的に学ぶには、OWASP Top 10の解説記事もあわせてご覧ください。