붙여 넣은 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)를 요구하세요.
본 사이트는 "비밀을 보유하지 않기", "소유가 증명된 것만 진단하기", "침해 시 피해 최소화"를 토대로 구축합니다(→ 본 사이트 소개).
SSRF vs CSRF vs 오픈 리디렉션
셋 다 외부에서 정한 목적지가 얽히지만, 무엇이 움직이고 어디까지 닿는지가 다릅니다.
| 공격 | 누가 어디로 가나 | 닿을 수 있는 곳 |
|---|---|---|
| SSRF | 내 서버가 지정된 목적지로 요청을 보낸다 | 내부 네트워크, 클라우드 자격 증명처럼 밖에서는 닿을 수 없는 곳 |
| CSRF | 사용자의 브라우저가 사용자가 의도하지 않은 요청을 보낸다 | 로그인한 사이트에서 그 사용자가 할 수 있는 일 |
| 오픈 리디렉션 | 사용자의 브라우저가 지정된 외부 사이트로 넘겨진다 | 가짜 사이트(피싱) |
SSRF가 특히 위험한 것은 닿는 곳이 "서버의 안쪽"이기 때문입니다. 방화벽이 밖으로부터 지키는 곳에도 서버를 거치면 닿을 수 있습니다.
실제 사례: 프레임워크의 기능에도 숨어 있다
SSRF는 직접 만든 "URL 가져오기" 기능뿐 아니라 프레임워크의 기능에서도 나타납니다. 예를 들어 최근 Next.js의 CVE에서는 외부 이미지를 가져오는 이미지 최적화 같은 서버 기능의 SSRF(CWE-918)가 가장 흔한 약점 유형 중 하나입니다(→ 실제 데이터로 본 Next.js와 React의 취약점(영문)). 2025년 12월 공개된 MITRE의 "CWE Top 25"(가장 위험한 소프트웨어 약점 25개)에서 SSRF는 22위입니다.
클라우드에서는 Capital One 침해가 대표적인 사례입니다. SSRF가 메타데이터 서비스에 닿았고, 권한이 과도한 임시 자격 증명이 탈취되었습니다. 2019년 11월 AWS는 이런 피해를 줄이기 위해 IMDSv2를 내놓았습니다.
내 환경에서 확인하는 방법
지정된 URL을 가져오는 곳을 모두 찾는다
코드에서 목적지에 사용자 입력이 들어갈 수 있는 HTTP 클라이언트(fetch, axios, requests 등)를 검색합니다. 링크 미리보기, 웹훅, 이미지 가져오기, PDF 생성, 가져오기(import) 기능이 전형적입니다.
프레임워크의 허용 설정을 확인한다
이미지 최적화나 외부 가져오기 설정에서 허용 호스트가 너무 넓지 않은지 확인합니다(Next.js라면 images.remotePatterns에 와일드카드만 있는 항목이 없는지).
IMDSv2를 필수로 한다(AWS)
각 EC2 인스턴스의 메타데이터 옵션에서 HttpTokens가 required(IMDSv2 전용)인지 확인합니다. 컨테이너를 돌리지 않는 서버라면 토큰 응답의 홉 제한을 1로 유지하세요.
서버의 외부 통신을 제한한다
URL을 가져오는 코드는 내부 네트워크에 닿지 않는 별도 환경에서 돌리거나, 외부 통신을 필요한 목적지로 한정합니다. 앱의 검증이 무언가를 놓쳐도 네트워크에서 멈춥니다.
출처(1차 자료)
- OWASP, "Server-Side Request Forgery Prevention Cheat Sheet" — cheatsheetseries.owasp.org(허용 목록, 내부 주소 차단, 리디렉션과 DNS 처리)
- AWS, "Use the Instance Metadata Service to access instance metadata" — docs.aws.amazon.com(IMDSv2 세션 토큰, required 설정, 홉 제한)
- AWS Security Blog, "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service"(2019년 11월) — aws.amazon.com
- Microsoft, "Azure Instance Metadata Service" — learn.microsoft.com(Azure도 169.254.169.254를 사용)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses"(2025년 12월) — cwe.mitre.org(CWE-918이 22위)
다음으로 읽기
- 용어집: RCE란 · CVE란
- 기초: 보안 기초
- 방어: X-Forwarded-For 위장과 신뢰된 프록시