백오피스

외부 링크 미리보기 생성(Unfurling) 시 서버 요청 위조(SSRF) 위험

증상 확인: 당신의 서버가 예상치 못한 곳에 접속하고 있나요?

외부 링크 미리보기(Unfurling) 기능은 사용자 경험을 향상시키는 편리한 도구입니다. 사용자가 게시한 URL의 메타데이터(제목, 설명, 썸네일 이미지)를 가져와 채팅방이나 게시판에 깔끔하게 보여줍니다. 그러나 이 편의성 뒤에 심각한 보안 위험이 숨어 있습니다. 당신의 애플리케이션 서버가 악의적으로 조작된 URL을 해석하는 과정에서, 내부 네트워크의 민감한 서비스(예: 메타데이터 서비스, 관리 인터페이스, 파일 시스템)에 직접 HTTP 요청을 보낼 수 있습니다. 이는 공격자가 외부에서 직접 접근할 수 없는 내부 시스템을 탐색하고 공격하는 발판이 됩니다.

원인 분석: 신뢰할 수 없는 입력과 과도한 권한

SSRF(Server-Side Request Forgery)가 발생하는 근본 원인은 두 가지로 요약됩니다. 첫째. 애플리케이션이 사용자로부터 입력받은 url을 충분히 검증하지 않고 백엔드 서버에서 직접 요청을 수행합니다. 둘째, 미리보기 기능을 처리하는 서버 컴포넌트가 과도한 네트워크 권한을 가지고 있어, 로컬호스트(127.0.0.1)나 사설 IP 대역(10.0.0.0/8, 192.168.0.0/16 등)에 대한 접근이 제한되지 않습니다. 공격자는 `http://169.254.169.254/latest/meta-data/` (AWS 메타데이터 서비스)나 `http://127.0.0.1:8080/admin` 과 같은 URL을 링크로 포스팅하여, 당신의 서버를 공격의 프록시로 이용할 수 있습니다.

해결 방법 1: 화이트리스트 기반의 허용 도메인 정책

가장 안전하고 구현이 직관적인 방법입니다. 애플리케이션에서 미리보기를 생성해도 안전하다고 판단된 신뢰할 수 있는 공개 도메인 목록을 미리 정의합니다. 모든 사용자 입력 URL은 이 목록과 비교하여, 허용 목록에 없는 도메인에 대해서는 미리보기 생성을 시도조차 하지 않습니다.

  1. 허용 도메인 목록 정의: 설정 파일(예: config/security.yml)이나 환경 변수에 다음과 같은 목록을 관리합니다.
    • youtube.com, youtu.be
    • twitter.com, x.com
    • newsite.com (회사 공식 블로그)
    • *.trusted-cdn.com (와일드카드 서브도메인 지원 고려)
  2. URL 파싱 및 검증 로직 구현: 사용자로부터 URL을 받으면, 호스트명(hostname)을 추출하여 허용 목록과 대조합니다. 이때, http://localhost@trusted.com 같은 ‘URL 내 임베디드 자격증명’ 공격을 방지하기 위해 표준 URL 파서를 사용해야 합니다.
  3. 검증 실패 시 처리: 허용 목록에 없는 도메인은 기본 미리보기(예: “안전하지 않은 링크”라는 제목과 기본 아이콘)로 대체하거나, 미리보기 생성 자체를 건너뜁니다.

이 방법은 관리 부담이 있지만, 위험 영역을 명확히 제한한다는 점에서 가장 확실한 방어선이 됩니다.

해결 방법 2: 네트워크 계층 격리 및 아웃바운드 제어

미리보기 생성 서비스를 전담하는 서버나 컨테이너를 네트워크 수준에서 격리시키는 방법입니다. 이 컴포넌트는 오직 외부 공개 인터넷으로의 아웃바운드 연결만 허용하고, 내부 사설 네트워크나 메타데이터 서비스에 대한 모든 접근을 차단합니다.

  1. 전용 서버/컨테이너 구성: Unfurling 로직을 메인 애플리케이션 서버와 분리하여 독립된 마이크로서비스로 배포합니다.
  2. 네트워크 정책 적용:
    • Docker: docker run --network none 또는 사용자 정의 브리지 네트워크를 사용하고, iptables 규칙으로 사설 IP 대역 차단.
    • Kubernetes: NetworkPolicy 리소스를 사용하여 파드(Pod)의 아웃바운드 트래픽을 특정 공인 IP 대역으로만 제한.
    • 클라우드: 전용 서브넷에 배치하고, 보안 그룹(Security Group)이나 NACL(Network ACL)에서 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16 등에 대한 아웃바운드 규칙을 명시적으로 거부(DENY).
  3. DNS 제한: 내부 DNS 서버를 사용하지 못하도록 하고, 공용 DNS(8.8.8.8 등)만 조회하도록 설정합니다, 이를 통해 내부 호스트명이 해석되는 것을 방지할 수 있습니다.

주의사항: 이 방법은 인프라 변경이 필요하며, 설정이 복잡할 수 있습니다. 예를 들어, 컨테이너 환경에서 --network none은 외부 인터넷 연결 자체를 차단할 수 있으므로, 외부 연결은 허용하되 내부 연결만 차단하는 세밀한 정책 구성이 필수입니다. 모든 네트워크 규칙을 적용한 후, 실제로 내부 IP로의 요청이 차단되는지를 반드시 테스트해야 합니다.

해결 방법 3: 안전한 HTTP 클라이언트 사용 및 입력 무결성 확보

애플리케이션 코드 레벨에서 요청 자체를 안전하게 만드는 기술적 조치입니다. 화이트리스트나 네트워크 격리와 함께 적용하면 방어 계층을 다층화할 수 있습니다.

  1. URL 스키마 및 포트 제한: http://와 https://만 허용합니다. 특히 공격자가 내부 서버의 핵심 파일에 접근하려 할 때 악용되는 file://, gopher://, dict:// 등의 위험한 스키마는 차단해야 합니다. 이러한 공격은 파일 시스템 권한 설정 오류로 중요 데이터 접근 노출이 발생한 환경에서 더욱 치명적인 피해를 입히기 때문입니다. 또한, 기본 포트(80, 443)가 아닌 임의의 포트 접근을 제한하는 정책을 고려합니다.
  2. 안전한 리졸버(Resolver) 사용: URL의 도메인을 IP로 변환(Resolve)할 때, 사설 IP나 루프백 IP로 변환되지 않도록 보장해야 합니다. 많은 프로그래밍 언어의 HTTP 클라이언트 라이브러리는 이 기능을 제공합니다.
    • Python (Requests): requests.get(url, allow_redirects=False) 후, 응답의 .raw._connection.sock.getpeername()으로 실제 연결된 IP를 검사. 또는 urllib3의 DummyResolver를 활용.
    • Node.js (node-fetch): dns.lookup 대신 dns.resolve를 사용하여 CNAME 레코드를 먼저 확인하고, 최종 IP가 사설 대역인지 검증하는 커스텀 리졸버 구현.
    • Go (net/http): 커스텀 DialContext 함수를 구현하여 연결 시도 전 대상 IP를 검증.
  3. 리다이렉트 제어: HTTP 3xx 리다이렉트를 무조건 따르게 하면, 초기에 허용된 URL이 최종적으로 내부 IP로 리다이렉트될 수 있습니다. 리다이렉트 횟수를 제한하고(예: 최대 2회), 각 리다이렉트 단계에서도 대상 URL에 대한 동일한 검증을 반복 수행해야 합니다.
  4. 요청 헤더 세정: 사용자 입력 URL에서 호스트 헤더를 그대로 사용하지 마십시오. 공격자가 http://your-backend.com@evil.com 같은 URL로 호스트 헤더를 조작할 수 있습니다. 요청을 보낼 때는 파싱한 호스트명을 명시적으로 헤더에 설정합니다.

주의사항: 지속적인 모니터링과 방어 계층화

지속적으로 진화하는 SSRF 공격은 새로운 메타데이터 서비스 엔드포인트나 IPv6 우회, 도메인 리다이렉션 등 변칙적인 기법을 동원하여 기존 보안망을 무력화합니다. 솔루션 아키텍처 조사 중 확인된 바로는 워드프레스쓰리테마즈 구성 환경에서 발견된 계층화된 제어 체계와 같이, 단일 보안 모듈에 전적으로 의존하기보다 다각적인 방어선을 병행 구축하여 대응력을 확보하는 것이 필수적입니다. 아웃바운드 요청에 대한 전수 로깅과 비정상적인 사설망 접근 시도를 실시간으로 탐지하는 감시 로직을 가동하고, 정기적인 모의 침투 테스트를 실시하여 현재의 보호 조치가 실질적인 방어 효용성을 갖췄는지 검증해야 합니다. 아울러 HTTP 클라이언트나 URL 파서 라이브러리의 보안 패치를 신속히 반영함으로써 소프트웨어 공급망의 취약점이 공격 경로로 활용될 가능성을 원천적으로 차단하는 통합적 관리가 수반되어야 합니다.

전문가 팁: 블랙리스트는 신뢰할 수 없음
사설 IP 대역이나 `localhost`, `169.254.169.254`를 블랙리스트로 차단하는 방법은 널리 알려져 있지만, 이것만으로는 충분하지 않습니다. 공격자는 IPv6(`::1`), 십진수 IP 표현(`2130706433`은 `127.0.0.1`), 도메인 리다이렉트, DNS 재귀 조회 등 다양한 우회 기술을 사용합니다. 블랙리스트는 최후의 보조 수단으로 간주하고, 가능하면 화이트리스트(허용 목록)와 네트워크 격리라는 적극적인 방어 전략에 집중하십시오. 또한, Unfurling 기능을 꼭 필요한 최소한의 서비스에서만 활성화하고, 관리자 패널이나 내부용 도구에서는 기본적으로 비활성화하는 정책을 검토하세요.