요약

  • 10월 27일자 개인 Internet-Draft는 구인·거래·교육 플랫폼의 내부 메시지에서 지원팀이나 채용 담당자를 흉내 내는 발신자를 다룬다. 새 통신 프로토콜을 정하지 않는 정보 제공용 초안이다.
  • 초안은 유니코드 뼈대의 완전 일치만 보는 검사와 보이지 않는 서식 문자를 남긴 채 호스트 이름을 받아들이는 일부 검증기를 문제로 든다. 발신자, 링크 목적지, 메시지가 요구하는 행동을 함께 보라고 제안한다.

구인 사이트의 받은 쪽지에 ‘공식 지원’이라고 적혀 있다. 그 말을 화면에 띄울 수 있다는 사실만으로 플랫폼 직원이라는 권한이 생기지는 않는다. 유사 발신자 탐지 초안은 메시지 한 건의 계정, 표시 이름, 주소, 링크 호스트와 요구 사항을 묶어 살피자고 한다. 앱 안의 두 계정 사이에는 수신자 회사의 메일 게이트웨이가 서 있지 않다. 어떤 계정이 공식 이름을 쓸 수 있는지 아는 쪽은 플랫폼이다.

초안은 단서를 세 갈래로 나눈다. 발신 도메인과 링크 호스트가 보호 대상 이름을 닮았는지 확인한다. 브랜드 표시 이름을 엉뚱한 주소에 붙였거나 주소의 일부에 그 이름을 숨겼는지 본다. 그리고 비밀번호 요구, 외부 사이트 이동, 플랫폼 권한 사칭처럼 수신자에게 시키는 일을 읽는다. 비슷한 이름 하나만으로 강하게 차단하면 대학 취업지원실 같은 정당한 발신자도 막는다. 이름과 의도를 함께 보는 이유다.

첫 번째 빈틈은 유니코드 비교식에 있다. Unicode UTS #39는 헷갈리는 문자들을 비교할 ‘뼈대’ 변환과 문자 체계 혼합 탐지를 설명한다. 초안에 따르면 뼈대의 완전 일치만 검사하는 구현은 눈에 비슷한 일부 이름을 놓친다. 그리스 소문자 카파와 키릴 소문자 테는 ASCII가 아닌 라틴 문자 원형으로 변환된다. ASCII로 쓴 보호 대상 이름과 최종 뼈대가 달라도 눈에는 가까워 보일 수 있다. 초안은 문자 체계 검사와 뼈대 사이의 제한된 편집 거리를 더하자고 제안한다.

두 번째 빈틈은 화면에 아예 보이지 않는다. 초안 작성자는 자신이 살펴본 여러 입력 검증기가 U+00AD, U+200B, U+2060 또는 U+FEFF를 포함한 호스트 이름을 받아들이고 문자를 그대로 돌려줬다고 기록했다. RFC 5890은 국제화 도메인 이름의 틀을, RFC 5892는 문자 코드 규칙을, Unicode UTS #46은 호환 처리를 설명한다. 초안은 허용 목록과 비교하기 전에 IDNA2008 또는 UTS-46으로 처리하고 서식 문자나 기본 무시 문자가 든 레이블을 거부하라고 한다. 숨은 문자를 품은 문자열에 ‘유효’ 도장을 찍으면 뒤의 프로그램이 잘못된 대상을 믿게 된다.

이름의 소유권을 정하는 곳은 도메인 등록부가 아니라 플랫폼 계정 관리다. 플랫폼은 보호할 지원 이름, 쓸 수 있는 계정, 경고와 차단의 경계를 정한다. 초안은 언어 모델이 문맥을 보조할 수 있다고 하면서도 메시지 본문을 믿을 수 없는 입력으로 다루고, 모델 판단이 확정적인 발신자 증거를 뒤집지 않게 하라고 요구한다. Datatracker에는 아직 개인 초안 I-D Exists, 예정 상태 Informational로 표시된다.

검증기 조사에 쓰인 라이브러리 이름과 버전, 재현 가능한 입력·출력 표는 초안에 없다. 그 표가 나와야 지금도 같은 결함이 어느 범위에 남아 있는지 확인할 수 있다.