"URL을 붙여 넣으면 그 내용을 가져와 드립니다" — 일상적인 편의 기능이지만, 최악의 경우 당신의 클라우드 자격 증명으로 가는 문이 됩니다. 그것이 SSRF입니다. 동작 원리와 방어법을 처음부터 설명합니다.
실제로 일어나는 일
정상 접근은 "사용자 → 외부 사이트"입니다. SSRF는 서버를 내부를 치는 프록시로 바꿉니다. 서버는 밖에서는 보이지 않는 내부 네트워크와 클라우드 자격 증명 엔드포인트에 닿을 수 있으므로 — 공격자가 그것을 간접적으로 엿봅니다.
169.254.169.254 (클라우드 자격 증명)클라우드에서 그 내부 엔드포인트(메타데이터 서비스)는 임시 자격 증명을 내줄 수 있습니다. SSRF가 거기에 닿으면 키가 탈취되어 공격이 스토리지 전체 탈취로 이어집니다 — 이것이 바로 Capital One 침해(2019)에서 일어난 일입니다. SSRF → 메타데이터 → IAM 자격 증명 → S3.
어디에 숨어 있는가
"서버가 사용자 제공 URL을 가져오는" 기능이라면 모두 후보입니다.
| 기능 | 전형적 구현 |
|---|---|
| OG / 링크 미리보기 | 서버가 붙여 넣은 URL을 가져와 썸네일을 만듦 |
| 웹훅 전송 | 서버가 사용자 지정 목적지로 POST |
| 이미지 / 파일 가져오기 | "URL에서 이미지 가져오기" |
| 사이트 진단 | 서버가 입력된 사이트에 접속해 검사 |
사람들이 놓치는 검증의 함정
"내부 IP 차단"만으로는 부족합니다. 이 구멍들도 닫아야 합니다.
단순한 차단은 새어 나간다
- 리디렉션 추적: 허용된 도메인이 내부 주소로
302한다. - DNS 리바인딩: 검증 시점엔 외부 IP, 가져오는 시점엔 내부 IP.
- IP 인코딩 트릭: 십진/팔진/축약 형태로 내부 주소를 위장.
- 이상한 스킴:
file://,gopher://등 예상치 못한 스킴.
기능을 만든다면 어떻게 방어하나
SSRF는 "기능을 어떻게 만드는가"에서 예방됩니다. 다음은 본 사이트가 자체 진단 기능에 부과하는 규칙입니다.
목적지에 허용 목록 사용
스킴(http/https)과 호스트를 허용된 집합만으로 제한하세요. "내부만 차단"보다 "이것들만 허용"이 더 튼튼합니다.
내부 대상 차단
127.0.0.1 / 10.x / 192.168.x / 169.254.169.254(메타데이터)로의 도달 가능성을 거부하세요.
사용자가 소유한 도메인만 (진단용)
사용자가 소유를 증명한 도메인으로 제한하세요. 제삼자 사이트를 겨냥하게 두지 마세요.
구멍을 닫고 메타데이터 보호
최종 리디렉션 대상을 검증하고, DNS 리바인딩을 고려하며, 클라우드에서는 토큰 기반 메타데이터(예: IMDSv2)를 요구하세요.
본 사이트는 "비밀을 보유하지 않기", "소유가 증명된 것만 진단하기", "피해 범위 최소화"를 토대로 구축합니다(→ 본 사이트 소개).
다음으로 읽기
- 용어집: RCE란 · CVE란
- 기초: 보안 기초
- 방어: X-Forwarded-For 위장과 신뢰된 프록시
FAQ
Q어떤 기능에 SSRF가 생기기 쉬운가요?
'서버가 사용자 제공 URL을 가져오는' 기능입니다. OG/링크 미리보기 생성, 웹훅 전송, 이미지 가져오기, 사이트 진단 등. 편리한 기능일수록 더 주의가 필요합니다.
QSSRF는 왜 클라우드에서 특히 위험한가요?
클라우드 VM에는 임시 자격 증명을 내줄 수 있는, 내부 전용 '메타데이터 엔드포인트'가 있습니다. SSRF가 거기에 닿으면 그 키가 탈취되어 공격이 스토리지 전체 탈취로 이어집니다(Capital One 침해의 경로).
QSSRF를 어떻게 방어하나요?
목적지를 허용 목록으로 엄격히 검증하고, 내부 IP(127.0.0.1, 10.x, 169.254.169.254 메타데이터)로의 도달 가능성을 차단하세요. 진단의 경우 사용자가 소유를 증명한 도메인으로 제한하고, 리디렉션 추적과 DNS 리바인딩 구멍을 닫으세요.