要約

  • RFC 1558 は LDAP のバイナリ Filter に前置記法の文字列表現を与えた。括弧、論理演算子、比較記号、* は説明用の記号ではなく検索条件そのものだった。
  • Filter は SearchRequest の一部にすぎない。ベース、スコープ、別名、制限、スキーマの照合規則、アクセス制御、属性選択、参照、最終結果を残さなければ実行内容は再現できない。
  • RFC 1960、RFC 2254、RFC 4515 は標準化状態、LDAPv3、UTF-8、オクテットのエスケープを更新した。Informational の RFC 1558 はセキュリティを論じておらず、導入規模や現在の脆弱性を証明しない。

括弧の内側は命令だった

RFC 1558 の記法では、すべてのフィルターが括弧に入る。& はすべての子条件、| は選択肢、! は否定を導く。(cn=Babs Jensen) は等価、(!(cn=Tim Howes)) はその否定である。長い例 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) は、Person であり、姓か common name の条件を満たす、という木構造になる。

ここで * は三つの顔を持つ。attr=* なら属性の存在、値の途中なら部分文字列、値そのものに星印を含めたいならエスケープされたデータである。目で見た差は小さいが、候補集合を決める権限は大きく変わる。

Datatracker と RFC Editor の記録 は、1993 年 12 月の Informational 文書で、インターネット標準ではないことを示す。テキスト版と正誤表は文書確認の別レイヤーである。本文はセキュリティ上の問題を論じないと明記した。したがって後世の「インジェクション」という語を、当時の事故報告として読み込んではならない。

可読化されたのは Filter だけ

RFC 1487 の SearchRequest には、BER で送られる Filter のほかに baseObject、scope、別名をたどる方針、件数と時間の制限、値を返すか、どの属性を求めるかが含まれていた。RFC 1558 はこのうち Filter を共通の文字列にした。RFC 1488は当時の属性値表現を支えたが、将来の全スキーマを固定したわけではない。

同じ文字列でも、基点が違えば探索領域が違う。singleLevel と wholeSubtree では候補数が違い、別名の解決は別の部分木へ進み得る。制限は途中で検索を止め、属性選択は一致後に何を返すかを変える。文字列だけを監査しても、検索全体は監査できない。

現行の RFC 4511 とその公式記録は、評価を TRUE、FALSE、Undefined の三値として扱う。TRUE のエントリーだけが返却候補になり、さらにアクセス制御を受ける。未知の属性、不適切な照合規則、無効な assertion value は Undefined になり得る。構文受理と意味の成立は別の証拠である。

検索結果も一つの返答ではない。SearchResultEntry と SearchResultReference がゼロ件以上届き、最後に SearchResultDone が来る。参照は未探索領域を示し、成功コードがあっても返却属性は制限され得る。一件の一致から完全検索、完全属性、認証、認可、後続処理の成功までを推論することはできない。

後継仕様がエスケープを精密化した

RFC 1960 は前置記法を保ちながら RFC 1558 を Proposed Standard として置き換えた。その履歴は状態ページに残る。

RFC 2254 と公式記録では LDAPv3 の extensible match と UTF-8 が入り、特殊なオクテットを反斜線と二桁の十六進数で表す方向が明確になった。

現在の RFC 4515 と状態記録は、*、左右括弧、反斜線、NUL のオクテットをエスケープし、有効な UTF-8 を生成するよう求める。(cn=*\2a*) では外側の星印が部分文字列演算子、\2a がリテラルの星印である。表示結果だけ保存し、元のオクテット、エスケープ処理、構文木を失えば、この違いを後から復元できない。

薄い共通契約を越えない

可読形式は運用を改善した。BER だけを見るより設定をレビューしやすく、アプリケーション間でテンプレートを共有しやすい。しかし表現の合意は、検索範囲、スキーマ、アクセス権、結果の利用まで合意したことを意味しない。

Heng Lu の最小初期仕様とローカルな将来判断を編集上の物差しにすると、RFC 1558 の価値は共通部分を狭くした点にある。Running-Code Primacyは実際のパーサーとサーバーの記録を求め、現実のレイヤーは表示文字列、解析木、BER、評価、返却データ、アプリの行為を分離する。

資料は特定の侵害、導入数、現行製品、露出データ、利用者の結果を示さない。後継 RFC があることも全実装の移行証明ではない。RFC 1558 の歴史的成果は Filter を見えるようにしたことだ。その見える表面が実行権限を隠さないようにする責任は、運用側に残った。

出典