요약

  • RFC 1558은 LDAP의 이진 검색 Filter에 사람이 읽을 수 있는 전위 표기법을 부여했다. 괄호,&,|,!, 비교 기호,*은 서술적 구두점이 아니라 실행 가능한 구조였다.
  • 필터는 SearchRequest의 한 필드일 뿐이었다. 기준 객체, 범위, 별칭, 한도, 스키마 매칭, 접근 제어, 요청 속성, 항목, 참조, 최종 결과가 각각 읽을 수 있는 문자열이 실제로 만들어내는 결과를 바꿨다.
  • 이후 RFC들은 이 표기법을 IA5 시대의 이스케이프에서 LDAPv3, UTF-8, 16진수 옥텟 이스케이프로 다듬었다. RFC 1558은 Informational 문서였고 보안 이슈를 논의하지 않았다. 문서 연쇄는 배포 사실도 현재의 취약성도 증명하지 않는다.

별표의 세 가지 삶

RFC 1558에서 가장 작게 드러나는 예는 회사도, 디렉터리도, 사건도 아니다. 한 문자다.

attr=*에서 별표는 존재를 의미한다. 지명된 속성이 존재하는 항목을 반환하라는 뜻이다. RFC의(o=univ*of*mich*)같은 값에서는 별표가 부분 문자열 패턴을 앞부분·중간 부분·뒷부분 구성 요소로 나눈다. 값 자체에*가 들어 있으면 1993년 메모는 그 앞에 백슬래시를 붙여 연산자가 아니라 데이터로 남도록 한다고 규정한다.

이것들은 인쇄상 변형이 아니다. 서로 다른 지시문이다. 보이는 문자열은 같은지 묻거나, 후보 집합을 넓히거나, 존재를 검사하거나, 한 조건을 다른 조건 안에 중첩할 수 있다. 익숙한 단어만 보는 검토자는 구두점이 담은 권한을 놓칠 수 있다.

RFC 1558의Datatracker 기록과RFC Editor 기록은 이 메모를 1993년 12월로 위치시키고 Informational 상태를 보존한다.보관 텍스트는 별도의 텍스트 대조를 제공하고,정오표 표면은 이후 수정 사항을 구분해 유지한다. 이 메모는 인터넷 표준을 명시하지 않았다고 분명히 밝혔고, 보안 절에서 보안 이슈는 논의되지 않았다고 말했다.

이 한계는 중요하다. 오늘날 이 표기법은 주입 형태의 위험을 알아보기 쉽게 만들지만, RFC 1558은 침해를 문서화하지 않았고 취약한 제품을 지명하지 않았으며 오용을 측정하지 않았다. 역사적 서술이 후대의 어휘를 근거에 몰래 되살려 넣어서는 안 된다.

읽을 수 있다는 것이 무해함을 뜻하지는 않았다

LDAP에는 이미 네트워크 Filter가 있었다.RFC 1487은 이를 SearchRequest 안에 담겨 BER으로 네트워크 인코딩되는 ASN.1 선택형으로 정의했다. RFC 1558이 한 일은 더 좁았다. 필터를 텍스트로 저장, 표시, 교환해야 하는 응용을 위해 공통의 사람이 읽을 수 있는 렌더링을 제공한 것이다.

문법은 전위 표기법을 사용했다. 모든 필터는 괄호 안에 놓였다.&는 모든 구성원이 일치해야 하는 목록을 도입했고,|는 대안을 도입했으며,!는 뒤따르는 필터를 부정했다. 단순 항목은 같음, 근사, 이상, 이하 비교를 지원했다. 존재 형식과 부분 문자열 형식은*에 두 가지 연산자 역할을 부여했다.

예제들이 구조를 보여준다:

  • (cn=Babs Jensen)은 같음 항목이다.
  • (!(cn=Tim Howes))는 같음 항목을 부정한다.
  • (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))는 필수 객체 클래스를 성 또는 일반 이름 접두 조건과 결합한다.

세 번째 줄은 구두점이 많은 텍스트처럼 보인다. 구문 분석하면 나무다. 뿌리는 AND, 한쪽 가지는 같음, 다른 가지는 같음과 부분 문자열 조건을 담은 OR이다. 서버는 사람의 시각적 인상에 동의할 필요가 없다. 서버는 자신이 받아들이는 문법에 따라 행동한다.

RFC 1558은 LDAPString을 IA5로 제한했고 속성 값의 문자열 형식은RFC 1488에 의존했다. 따라서 보이는 표기법은 모든 미래의 디렉터리 값을 위한 보편적 렌더링이 아니었다. 그것은 특정 프로토콜과 문법 시대에 속한 것이었다.

필터가 검색 전부는 아니었다

완벽하게 재구성된 Filter조차 LDAP 검색을 재현하지 못한다. 원래 SearchRequest는 또한 기준 객체를 지명하고, 기준 전용·한 수준·전체 하위 트리 범위를 선택하고, 별칭 역참조 정책을 정하고, 크기와 시간 한도를 공급하고, 값을 반환할지 선택하고, 속성을 선택했다.

이 둘러싼 봉투가 작업을 바꾼다. 다른 기준 객체 아래의 같은 술어는 디렉터리의 다른 부분을 방문한다. 같은 기준 객체와 필터라도 전체 하위 트리 범위는 한 수준 검색보다 더 많은 항목을 고려한다. 별칭 역참조는 다른 객체를 순회로 끌어들일 수 있다. 한도는 모든 잠재적 일치가 반환되기 전에 검색을 멈출 수 있다. 속성 선택은 항목이 일치한 뒤 클라이언트가 보도록 요청하는 것을 제어한다.

현재 프로토콜인RFC 4511은 이 구분을 직접 서술한다. 검색은 접근 제어와 기타 제한을 조건으로 복잡한 기준에 일치하는 항목을 서버에 반환하도록 요청한다. 그공식 기록은 문서를 식별할 뿐, 어떤 특정 작업에 대한 영수증이 아니다.

RFC 4511에서 필터 평가는 삼값이다. TRUE, FALSE 또는 Undefined. 항목은 필터가 TRUE로 평가될 때만 반환되며, 그 경우에도 접근 제어가 적용된다. 인식되지 않는 속성 서술, 부적합하거나 알 수 없는 매칭 규칙, 유효하지 않은 어설션 값은 Undefined를 만들 수 있다. 구문상 받아들여진 문자열이 서버가 모든 항목을 저자가 기대한 대로 이해했다는 증명은 아니다.

일치, 반환, 완료는 서로 다른 사건이었다

LDAP 검색 출력은 단일 판정이 아니다. RFC 4511은 0개 이상의 SearchResultEntry 및/또는 SearchResultReference 메시지 뒤에 하나의 SearchResultDone이 오는 것을 정의한다. 항목과 참조는 어떤 순서로도 도착할 수 있다. 참조는 그 검색이 아직 탐색하지 않은 영역을 표시한다. 최종 메시지는 성공 또는 오류를 보고한다.

항목은 클라이언트가 상상할 수 있는 모든 값을 담고 도착하지 않을 수도 있다. 요청은 유형만 요구할 수 있고, 접근 제어는 값을 억제할 수 있으며, 관리 정책이 값을 제한할 수 있고, 운영 속성은 자동으로 반환되지 않는다. “필터가 일치했다”와 “클라이언트가 완전한 레코드를 받았다”는 서로 다른 주장이다.

이 구분은 허위 승격 사슬을 막는다:

  1. 필터 문자열이 구문 분석되었다;
  2. BER Filter가 전송되었다;
  3. 서버가 이를 평가했다;
  4. 한 항목이 TRUE로 평가되었다;
  5. 항목 메시지가 반환되었다;
  6. 선택된 속성이 접근 정책을 통과했다;
  7. 검색이 제한 오류나 미탐색 참조 없이 완료되었다;
  8. 응용이 항목을 선택했다;
  9. 주체가 인증되고 이후 행위에 대해 권한을 부여받았다;
  10. 그 행위가 성공했다.

각 단계에는 자신의 영수증이 필요하다. 첫 줄이 합리적으로 보였다는 이유만으로 어떤 것도 함축되지 않는다.

문법이 계속 바뀐 이유는 경계가 실재했기 때문이다

RFC 1960— 그상태 기록이 표준 트랙에서 RFC 1558을 대체했음을 보여준다 — 은 알아볼 수 있는 전위 형식과 문자 이스케이프 접근을 유지했다. 그 자체가 RFC 2254로 대체되었다.

RFC 2254는 확장 매칭을 포함해 LDAPv3에 맞춰 표기법을 확장하고 UTF-8 환경으로 이동했다. 그문서 기록은 연쇄 속 그 위치를 보존한다. 특수 옥텟은 이전 메모의 세 특수 문자 앞에 백슬래시를 붙이라는 느슨한 지시 대신, 백슬래시 뒤 두 자리 16진수로 표현되었다.

현재 필터 문자열 명세인RFC 4515— 그RFC Editor 기록으로 식별된다 — 은 인코딩 경계를 더 정밀하게 만든다.*,(,), 백슬래시, NUL의 옥텟을 이스케이프할 것을 요구하고 생성된 문자열을 유효한 UTF-8로 제한한다. 그 예제(cn=*\2a*)는 일반 이름 안의 리터럴 별표를 검색한다. 바깥 별표는 부분 문자열 연산자로 남고\2a는 데이터를 나타낸다.

이것은 단지 방어적 구두점이 아니다. 재현 가능성 규칙이다. 캡처가 디코딩된 표시 문자열만 저장하고 원래 옥텟, 이스케이프 루틴, 파서 결과를 버리면, 조사자는 별표가 술어를 넓혔는지 어설션된 값에 속했는지 판별하지 못할 수 있다.

얇은 계약은 가치가 있었다

교훈은 읽을 수 있는 표현이 안전하지 않다는 것이 아니다. 공통 텍스트 형식이 없다면 응용들은 호환되지 않는 문법을 발명하거나 불투명한 BER을 노출했을 것이다. 운영자는 구성을 검토하고, 검색 템플릿을 교환하고, 동작을 진단하기가 더 어려웠을 것이다.

RFC 1558은 좁은 번역 표면을 표준화했다. 하나의 프로토콜 객체를 공유 텍스트 형식으로 쓸 수 있게 한 것이다. 디렉터리 내용, 스키마 시대, 접근 정책, 응용이 선택한 기준 객체, 결과로 취해진 행동은 표준화하지 않았다. 그 절제가 얇은 계약의 강점이다.

Lu Heng의Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption은 편집적 렌즈를 제공한다. 공통 구조는 최소이고 결정적이어야 하며, 지역 정책에 의존하는 결정은 식별 가능하고 되돌릴 수 있어야 한다는 것이다. 이 비유는 회고적이며 RFC 저자의 의도에 대한 주장이 아니다.

그의Running-Code Primacy는 근거 조사를 실제로 돌아간 파서와 서버로 향하게 한다. RFC는 표기법이 종이 위에서 무엇을 의미했는지 알려준다. 어떤 제품이 어떤 문법을 받아들였는지, 서버가 어떤 검색을 실행했는지는 알려주지 않는다.Reality-layer discipline은 이어서 표시 문자열, 구문 분석된 나무, BER 요청, 평가, 반환된 데이터, 응용 결과가 하나의 안심되는 라벨로 붕괴하지 않도록 유지한다.

1993년 자료가 증명할 수 없는 것

근거는 익스플로잇, 영향받은 설치, 노출된 디렉터리, 현재 제품, 사용자 결과를 지명하지 않는다. 채택을 측정하지 않고 패킷 캡처를 제공하지 않는다. RFC 1558의 Informational 상태는 문서적 분류일 뿐, 소프트웨어가 그에 부합했다는 증거가 아니다. 이후 표준들은 기술적 계승을 보여줄 뿐, 보편적 이행은 아니다.

또한 올바른 이스케이프가 넓은 접근을 허가하지 않는다. 완벽하게 인코딩된 필터도 여전히 광대한 질문을 할 수 있다. 서버는 그것을 올바르게 평가하고 데이터를 올바르게 거부할 수 있다. 반대로 좁은 필터는 범위나 별칭 정책이 바뀌어 예상보다 넓은 하위 트리 위에서 작동할 수 있다. 보안 검토는 하나의 문자열이 아니라 완전한 작업에 속한다.

RFC 1558의 지속적 기여는 숨겨진 프로토콜 객체를 논의 가능하게 만든 것이었다. 그 지속적 경고는 더 조용하다. 운영자가 읽을 수 있는 텍스트를 통해 실행 가능한 구조를 입력하는 순간, 제어 표면은 파서에서 시작하여 결과가 경계 지어지고 귀속되고 행동해진 뒤에야 끝난다.

출처