DNS 리바인딩은 공격자가 제어하는 웹 페이지가 공격자의 호스트명으로 접근 가능한 내부 HTTP 서비스에 요청하게 만들 수 있다. 성공 여부는 브라우저 보호·이름 해석·연결 동작·대상 서비스에 달렸다. 페이지를 열었다고 모든 기기에 접근되는 것은 아니다. 이 글은 경계와 방어 점검을 설명하며 DechoNet이 수행한 공격 실험을 보고하지 않는다.

호스트명은 고정된 접속 대상이 아니다

MDN 동일 출처 정책 문서에서 출처는 스킴·호스트·포트의 조합이다. 해석된 IP는 이 조합에 들어가지 않는다. 교차 출처 읽기는 일반적으로 제한되지만 일부 요청·리소스 삽입은 가능하다. CORS는 인증이 아니며 모든 요청이 서버에 도착하는 것을 막지 않는다.

단순화한 HTTP 예에서는 공격자가 제어하는 호스트명과 공용 IP에서 페이지를 읽은 뒤 같은 호스트명을 다시 해석했을 때 내부 주소를 돌려준다. 브라우저가 같은 스킴·포트로 그 주소에 연결하고 서비스가 호스트명과 요청을 받아들이면 스크립트가 동일 출처로 접근할 수 있다. 낮은 DNS TTL만으로 새 조회가 보장되지는 않는다. 리졸버·운영체제 캐시와 지속 연결도 영향을 준다. HTTPS라면 대상이 해당 호스트명의 TLS 검증까지 통과해야 하므로 일반 내부 HTTPS 서버를 그대로 바꿔 끼울 수는 없다.

2007년 스탠퍼드 논문은 당시 브라우저·플러그인의 리바인딩과 DNS 피닝을 연구했다. 실험 규모는 역사적 근거이며 현재 브라우저의 공격 성공률이 아니다. 호스트명을 주소에 고정하는 피닝은 도움이 되지만 애플리케이션 방어를 캐시 타이밍에만 의존해서는 안 된다.

방어에는 적용 범위가 있다

2023년 Intruder 연구, 2024년 갱신은 IPv6와 A/AAAA 응답·연결 동작을 이용한 빠른 리바인딩을 설명한다. IPv4 A 레코드 두 개를 주기만 하면 현재 Chrome·Safari에서 항상 성공한다는 근거는 아니다.

리졸버에서는 dnsmasq 매뉴얼의 --stop-dns-rebind가 상위 서버의 사설 주소 응답을 거부한다. localhost와 도메인별 예외도 문서화돼 있다. 실행 중인 설정과 예외를 확인해야 한다. 설치돼 있다는 사실만으로 보호가 켜졌거나 모든 클라이언트가 그 리졸버를 사용한다고 판단할 수 없다.

Oligo의 2024년 공개는 시험한 Linux·macOS 환경에서 0.0.0.0 요청이 로컬 서비스에 도착함을 보였다. CORS 때문에 응답을 읽지 못해도 요청은 처리될 수 있었다. DNS 변경 없이도 가능한 관련 로컬 접근 문제다. 공개 당시의 브라우저 수정 상태를 현재 모든 브라우저의 동작으로 일반화할 수는 없다.

Chrome 142는 Local Network Access 제한을 도입했다. 적용 대상인 로컬 주소·루프백 요청은 권한의 영향을 받으며 이 권한은 보안 컨텍스트로 제한된다. 설계 문서는 이전 PNA 계획을 대체한 경위를 설명한다. 적용 범위는 버전·요청 방식에 따라 달라지며 권한 창이 서비스 인증을 대신하지 않는다.

내부 서비스 운영자가 확인할 항목

  1. LAN·루프백 서비스에도 인증·인가를 요구한다. 상태를 바꾸는 브라우저 요청은 CSRF로부터 보호한다. 응답 읽기를 막는 것만으로 부족하다.
  2. 임의의 공용 호스트명을 받아들이지 말고 예상한 HTTP Host/authority를 검증한다. 인증과 함께 적용해야 한다. 호스트명 허용 목록만으로 모든 직접 교차 출처 요청을 막지는 못한다.
  3. 기기 펌웨어·브라우저를 갱신하고 네트워크 접근 범위와 리졸버 예외를 점검한다. 브라우저 기능 하나가 모든 클라이언트를 보호한다고 가정하지 않는다.
  4. DNS 조회와 HTTP 헤더는 공개 서버 관측에만 사용한다. DechoNet은 사용자의 LAN에 리바인딩을 시험하거나 내부 서비스의 인증을 보증하지 않는다. 공개 점검의 범위는 판정 방법에서 확인할 수 있다.

서비스가 자기 접근 경계를 직접 집행해야 한다. 브라우저·리졸버 제한은 추가 방어이며 인증 없는 로컬 제어 API를 노출해도 된다는 근거가 아니다.