Host Split Attack

Host Split Attack

URL 안의 호스트명(Hostname)을 처리하는 과정에서, 일부 Unicode 문자가 정규화(normalization)/IDN 처리 과정에서

. / : @ # 같은 URL 구조를 바꾸는 문자처럼 변형되면서, 프로그램이 처음 이해한 호스트의 실제 전송 이동 시점의 호스트가 달라지는 취약점이다.

 

핵심은 보안 판단은 원래 문자열 기준으로 했는데, 나중에 정규화 후 URL 구조가 바뀌어 다른 도메인으로 해석된다는 것이다.

 

쉽게 말해,

trusted.example 안의 하위 도메인이라고 믿었는데, Unicode/IDNA 변환 뒤에는 evil.example/path.trusted.example 같은 전혀 다른 구조로 바뀌어 오픈 리다이렉트 우회, OAuth 토큰 탈취, 도메인 검증 우회 같은 문제가 생길 수 있다.

 

발생원인

국제화 도메인 이름(IDN) 처리이다. DNS는 실질적으로 ASCII 기반으로 동작하므로, Unicode 도메인은 IDNA 규칙에 따라 ASCII 형태(A-label, 흔히 punycode)로 바꿔서 사용한다.

이 과정에서 일부 구현은 IDNA2008 대신 호환성 처리를 섞거나, 정규화 전/후에 URL을 잘못 분해해서, 원래는 평범해 보이던 Unicode 문자가 구조적으로 의미 있는 문자로 변해버릴 수 있다.

RFC 5891은 IDNA 프로토콜을 정의 하고, UTS #46은 호환성 처리를 제공하는데, HostSplit은 바로 이런 정규화와 URL 파싱 경계에서 발생한다.

 

예를 들어, ℀ (U+2100, ACCOUNT OF) 이 문자가 어떤 구현에서는 IDN/정규화 과정에서 a/c로 바뀔 수 있는데 그럼 원래 하나의 hostname label처럼 보이던 것이 / 를 포함하게 되어 URL의 호스트와 경로 경계가 깨진다.

http://canada.c℀.products.office.com/test.exe

• 애플리케이션은 이걸 보고 products.office.com 하위 도메인이라고 생각

취약한 변환 로직이 ℀ -> a/c 로 처리하면 최종 URL은 

http://canada.ca/c.products.office.com/test.exe

• canada.c℀.products.office.com이라는 하나의 host 였던 것이
• canada.ca라는 다른 host와 /c.products.office.com 라는 path로 분리됨

---

취약점 형태

1. 오픈 리다이렉트 우회

허용된 도메인으로만 redirect하게 만든 로직을 우회해서, 실제로는 공격자 사이트로 보낼 수 있다.

이는 로그인 후 이동, 결제 후 복귀, SSO 리다이렉트 등에서 치명일 수 있다.

2. OAuth 토큰 탈취

redirect_uri 검증이 문자열상 허용 도메인 기준이면, 정규화 후 구족 바뀌며 공격자 도메인으로 토큰이나 authorization code가 전달될 수 있다.

 

---

어떤 문자들이 문제가 되나

 

• ℀ (U+2100) ☞ /: 경로(path) 시작/구분
• ⁈ (U+2048) ☞ ?:query 시작 / !:URL 표준 구조문자는 아니지만, 어떤 애플리케이션 로직에서는 특수 의미로 다뤄질 수 있음
• ： (FULLWIDTH COLON) ☞ : 스킴 뒤 구분자(http:), 호스트 뒤 포트 구분자( :80 )
• ／ (FULLWIDTH SOLIDUS) ☞ / : 경로(path) 시작/구분
• ＃ (FULLWIDTH NUMBER SIGN) ☞ #: fragment 시작
• ＠ (FULLWIDTH COMMERCIAL AT) ☞ @: userinfo와 host 구분

---

방어기법

1. 보안 판단은 ASCII hostname 기준

• 사용자 입력에서 URL에서 host를 먼저 안전하게 분리
• host를 ToASCII / A-label로 정규화
• 그 정규화된 ASCII 결과로 화이트리스트 비교

2. URL 전체를 먼저 문자열 비교하지 말 것

먼저 표준 URL 파서로 분해한 뒤, 정규화된 host만 비교해야 한다.

endsWith("trusted.com")		// 위험
contains("trusted.com")		// 위험

 

3. URL 재조립 전에 host를 별도로 검증

검사 전에 정규화가 아닌

파싱 → host 추출 → host ToASCII → 허용 여부 판단 → 그 결과만 사용 순서로 처리

---