SSRF(Server-Side Request Forgery, 서버측 요청 위조)
1. 개요
정의: SSRF(Server-Side Request Forgery)는 공격자가 서버 애플리케이션이 외부 자원을 가져오기 위해 사용하는 URL·주소 파라미터를 조작하여, 신뢰받는 서버가 공격자가 지정한 내부망·클라우드 메타데이터·외부 엔드포인트로 대신 요청을 보내도록 강제하는 취약점이다. 즉 서버를 공격자의 "대리 요청기(proxy)"로 전락시키는 공격이다.
현대 애플리케이션은 외부 URL을 입력받아 서버가 그 자원을 가져오는 기능을 광범위하게 사용한다. 웹훅(webhook) 등록, 원격 이미지 썸네일 생성, URL 미리보기, PDF 렌더링, 외부 API 연동, 파일 임포트가 대표적이다. 이때 서버는 사용자가 넘긴 URL을 그대로 신뢰해 요청을 수행하는데, 문제는 그 서버가 방화벽 안쪽의 신뢰된 네트워크 위치에 있다는 점이다. 외부 공격자가 직접 닿을 수 없는 내부 관리 포트, 데이터베이스, 클라우드 메타데이터 서비스에 서버는 아무 제약 없이 접근할 수 있다. SSRF는 바로 이 "서버의 네트워크 신뢰 위치"를 공격자가 빌려 쓰는 구조적 약점을 악용한다.
이러한 "서버가 외부 자원을 대신 가져오는" 패턴은 특정 분야에 국한되지 않고 사실상 모든 현대 서비스에 편재한다. SNS의 링크 카드 미리보기, 쇼핑몰의 외부 이미지 등록, 협업툴의 파일 임포트, CI/CD 파이프라인의 외부 아티팩트 다운로드, 챗봇·에이전트의 외부 URL 조회가 모두 잠재적 SSRF 지점이다. 기능이 편리할수록 "사용자가 지정한 주소로 서버가 나간다"는 동작이 늘어나므로, SSRF는 기능 확장과 공격면 확대가 비례하는 전형적 보안-편의 긴장 관계를 보여준다. 그러므로 SSRF는 "없앨 기능"이 아니라 "안전하게 설계해야 할 기능 패턴"으로 다뤄야 한다.
이 위협이 급부상한 배경에는 클라우드·마이크로서비스 아키텍처의 확산이 있다. 온프레미스 단일 서버 시절에는 내부망 자원이 적었지만, 클라우드에서는 모든 인스턴스가 169.254.169.254 라는 링크로컬 메타데이터 엔드포인트를 통해 임시 자격증명(IAM 역할 토큰)을 조회할 수 있다. SSRF 한 건이 곧바로 클라우드 전체 권한 탈취로 번질 수 있게 된 것이다. 그 심각성 때문에 OWASP는 2021년 개정판에서 SSRF를 A10:2021 — Server-Side Request Forgery라는 독립 항목으로 처음 분리했으며, 이는 종전 "인젝션"이나 "접근통제 결함"에 묻혀 있던 위협을 커뮤니티 설문에서 1순위로 꼽은 결과를 반영한 것이다. 정보관리기술사 관점에서 SSRF의 본질은 단순 입력 검증 버그가 아니라, 신뢰 경계·네트워크 분할·최소권한을 아우르는 아키텍처 설계 결함으로 보아야 한다.
SSRF가 다른 웹 취약점과 구별되는 특징은 세 가지다. 첫째, 권한의 비대칭 악용이다. 공격자는 아무 권한이 없지만 서버는 내부망에서 광범위한 권한을 가지므로, 공격자는 자신의 무권한 상태를 서버의 고권한 상태로 "증폭"시킨다. 둘째, 연쇄성(chaining)이다. SSRF 자체는 "요청을 대신 보내게 하는" 것일 뿐이지만, 그 끝에 메타데이터·내부 Redis·관리 API가 놓이면 자격증명 탈취, 원격코드실행(RCE), 측면 이동으로 이어진다. 셋째, 탐지 사각지대다. 서버가 보내는 내부 요청은 정상 트래픽과 구분하기 어렵고, 특히 Blind 유형은 응답이 없어 로그만으로 공격을 식별하기 쉽지 않다. 이 세 특징 때문에 SSRF는 단독 취약점의 CVSS 점수보다 실제 사고 파급이 훨씬 큰 "증폭형" 위협으로 평가된다.
2. 공격 구조와 위협 모델
SSRF를 이해하는 핵심은 "누가 요청을 보내는가"의 전환이다. 일반적인 공격은 공격자의 단말이 직접 표적에 패킷을 던지지만, SSRF에서는 정당한 권한을 가진 서버가 공격자를 대신해 요청을 발사한다. 그 결과 외부에서는 닫혀 있는 내부 자원이 서버의 눈으로는 열려 있고, 방화벽·네트워크 ACL은 "서버가 보낸 내부 통신"으로 인식해 통과시킨다.
전통적인 경계 보안(perimeter security)은 "외부는 위험, 내부는 안전"이라는 전제 위에 세워졌다. SSRF는 바로 이 전제를 무너뜨린다. 외부 공격자의 의도가 내부에서 출발한 신뢰된 요청으로 둔갑하기 때문이다. 이 때문에 SSRF 방어는 경계 방화벽만으로는 불가능하며, 뒤에서 다룰 제로트러스트적 사고 — "내부에서 오는 요청도 검증하고 최소권한으로 제한한다" — 와 자연스럽게 연결된다.
flowchart LR
ATK(("공격자")) -->|"조작된 URL 입력"| APP["웹 애플리케이션 서버<br/>(신뢰된 네트워크 위치)"]
APP -->|"정상 외부요청"| EXT["외부 정상 자원"]
APP -.->|"악용된 내부요청"| META["클라우드 메타데이터<br/>169.254.169.254"]
APP -.->|"악용된 내부요청"| INT["내부 서비스<br/>(DB·관리콘솔·캐시)"]
APP -.->|"프로토콜 전환"| FILE["file:// gopher://<br/>내부 프로토콜"]
META -.->|"IAM 임시자격증명"| APP
FW["방화벽 / ACL"] -. "외부→내부 차단" .-x ATK
위 구조도의 핵심은 방화벽이 공격자의 직접 접근(점선 차단선)은 막지만, 서버가 내부로 보내는 요청은 신뢰해 허용한다는 점이다. 공격자는 입력창에 http://169.254.169.254/... 같은 내부 주소를 넣는 것만으로 이 신뢰를 가로챈다. 즉 SSRF의 피해 크기는 "서버가 무엇을 입력받는가"가 아니라 "서버가 내부적으로 무엇에 닿을 수 있는가"에 비례한다. 따라서 위협 모델링에서는 애플리케이션의 송신(egress) 권한과 인접 내부 자원의 민감도를 먼저 평가해야 한다.
둘째, SSRF는 응답 반환 여부에 따라 성격이 크게 갈린다. 서버가 가져온 내용을 화면에 되돌려 주면(In-band SSRF) 공격자는 내부 자원의 내용을 직접 읽어낼 수 있다. 반면 응답이 돌아오지 않더라도(Blind SSRF) 응답 시간 차이, 에러 메시지, DNS 조회 발생 여부 같은 부채널(side-channel)로 내부 존재 여부를 추론하거나 내부 API의 상태 변경(쓰기) 요청을 날릴 수 있다. 다음 세부 시퀀스는 클라우드 메타데이터를 노린 전형적 공격 흐름이다.
sequenceDiagram
participant ATK as 공격자
participant SRV as 애플리케이션 서버
participant IMDS as 메타데이터 서비스(IMDSv1)
participant S3 as 클라우드 스토리지
ATK->>SRV: "image_url=http://169.254.169.254/latest/meta-data/iam/..."
SRV->>IMDS: 서버가 대신 GET 요청
IMDS-->>SRV: IAM 역할 임시 자격증명 반환
SRV-->>ATK: 응답 본문에 자격증명 노출
Note over ATK: 탈취한 키로 직접 인증
ATK->>S3: 유효한 자격증명으로 접근
S3-->>ATK: 민감 데이터 유출
이 흐름에서 주목할 점은 공격 성립 지점이 애플리케이션 입력 한 곳이지만, 최종 피해는 전혀 다른 서비스(스토리지)에서 비가역적으로 발생한다는 것이다. 단일 취약점이 권한 상승·측면 이동으로 연쇄된다는 점에서 SSRF는 "진입점(entry point)" 취약점으로 분류된다.
위협 모델을 정량적으로 다루려면 "서버가 닿을 수 있는 내부 자원의 집합"을 공격 표면으로 명시해야 한다. 예를 들어 하나의 애플리케이션 서버가 동일 VPC 안의 마이크로서비스 30개, 메타데이터 엔드포인트, 내부 캐시, 로그 수집기에 네트워크적으로 닿을 수 있다면, SSRF 성공 시 공격자는 그 34개 자원 전체를 잠재적 표적으로 얻는다. 반대로 송신 트래픽을 전용 프록시 한 곳으로만 묶고 그 외 egress를 차단하면, 같은 SSRF가 발생해도 공격자가 닿을 수 있는 자원은 "프록시가 허용한 목적지"로 축소된다. 즉 SSRF의 실질 위험도는 코드가 아니라 네트워크 토폴로지가 결정한다는 점이 위협 모델링의 출발점이다.
3. 공격 유형
SSRF는 응답 반환 방식, 표적, 프로토콜에 따라 여러 유형으로 나뉜다. 각 유형은 탐지 난이도와 대응 전략이 다르므로 구분이 중요하다.
A. In-band(기본) SSRF. 서버가 가져온 외부 자원의 내용을 응답에 그대로 포함해 돌려주는 경우다. 공격자는 내부 포트 스캔 결과, 설정 파일, 메타데이터 자격증명을 직접 눈으로 확인할 수 있어 가장 즉각적이고 위험하다. URL 미리보기나 이미지 프록시 기능에서 자주 발생한다.
B. Blind(맹목) SSRF. 서버가 요청은 수행하지만 결과를 응답에 반환하지 않는 경우다. 공격자는 외부에 자신이 통제하는 수집 서버(예: Burp Collaborator, DNS 로깅 도메인)를 두고, 서버가 그 도메인을 조회·접속하는지로 취약점 존재를 확인한다. 직접 데이터를 읽지는 못하지만, 상태 변경 API 호출이나 내부망 매핑에 악용될 수 있다.
C. 반맹목(Semi-blind) SSRF. 응답 본문은 없지만 HTTP 상태코드·응답 시간·에러 메시지 같은 간접 신호로 내부 서비스의 존재나 응답을 추론하는 유형이다. 포트가 열렸는지 여부를 응답 지연으로 구별하는 내부 포트 스캐닝이 대표적이다.
D. 프로토콜 전환형 SSRF. 공격자가 http가 아닌 file://, gopher://, dict://, ftp:// 스킴으로 전환해 로컬 파일 읽기나 평문 프로토콜 기반 내부 서비스(Redis·Memcached·SMTP)를 직접 조작하는 유형이다. 특히 gopher://는 임의 바이트 스트림을 보낼 수 있어 인증 없는 내부 Redis에 쓰기 명령을 주입하는 등 가장 파괴적이다. 이 유형은 단순 정보 노출을 넘어 내부 서비스의 상태를 바꾸거나, 조건이 맞으면 원격코드실행(RCE)까지 이어질 수 있어, 허용 스킴을 엄격히 제한하지 않은 시스템에서 치명적 결과를 낳는다.
| 유형 | 응답 반환 | 주요 악용 | 탐지 난이도 |
|---|---|---|---|
| In-band | O(본문) | 메타데이터·내부파일 직접 읽기 | 낮음 |
| Blind | X | 상태변경 API·외부 콜백 유도 | 높음 |
| 반맹목 | 부분(상태·시간) | 내부 포트스캔·존재 추론 | 중간 |
| 프로토콜 전환 | 경우별 | Redis·SMTP 조작, 파일읽기 | 중간 |
이 분류가 실무에서 중요한 이유는 유형별로 탐지·대응 전략이 달라지기 때문이다. In-band는 응답 본문에 민감정보가 실리므로 출력 필터링과 응답 최소화가 1차 방어선이지만, Blind·반맹목은 애초에 서버가 내부로 요청을 보내지 못하게 하는 egress 통제가 유일하게 확실한 대책이다. 프로토콜 전환형은 허용 스킴을 http/https로만 제한하고 요청 라이브러리의 비표준 스킴 지원을 비활성화하는 별도 조치가 필요하다. 따라서 침투테스트·코드리뷰 시에는 "이 기능이 어떤 SSRF 유형에 취약한가"를 먼저 분류한 뒤 그에 맞는 방어를 매핑하는 접근이 효율적이다.
4. 주요 공격 표적과 우회 기법
SSRF의 표적은 "서버가 닿을 수 있으나 외부에서 닿을 수 없는" 모든 자원이다. 첫째는 앞서 본 클라우드 메타데이터 서비스다. AWS·GCP·Azure 모두 169.254.169.254를 쓰며, 여기서 인스턴스에 부여된 IAM 역할의 임시 자격증명을 조회할 수 있다. 둘째는 내부 관리 인터페이스로, 외부에 노출하지 않은 관리자 콘솔, Kubernetes API 서버, 액추에이터(actuator) 엔드포인트, 서비스 디스커버리 등이 대상이 된다. 셋째는 인증 없는 내부 데이터 저장소(Redis·Elasticsearch·Memcached)로, 평문 프로토콜을 쓰는 경우 프로토콜 전환형 SSRF에 특히 취약하다.
방어 측이 단순 차단만으로 막기 어려운 이유는 우회 기법이 다양하기 때문이다. 공격자는 http://127.0.0.1을 http://127.1, 8진수·16진수·정수 표기(http://2130706433), IPv6 축약(http://[::1])으로 변형해 블랙리스트를 회피한다. 또한 공격자가 통제하는 도메인의 DNS 응답을 검증 직후 내부 IP로 바꾸는 DNS 리바인딩(DNS Rebinding), 정상 외부 URL로 검증을 통과한 뒤 3xx 리다이렉트로 내부 주소로 유도하는 기법, URL 파서와 요청 라이브러리가 @·#·공백을 다르게 해석하는 파서 불일치(parser confusion) 공격이 있다. 이처럼 "문자열 수준의 블랙리스트"는 근본 대책이 될 수 없으며, 뒤에서 다룰 네트워크 계층 통제가 필요하다.
| 표적 | 대표 주소/프로토콜 | 노리는 것 |
|---|---|---|
| 클라우드 메타데이터 | 169.254.169.254 | IAM 임시 자격증명 |
| 내부 관리 API | 10.0.0.0/8, k8s API | 권한 상승·구성 탈취 |
| 내부 데이터저장소 | redis://, gopher:// | 데이터 조작·RCE |
| 로컬 파일 | file:// | 설정·비밀키 읽기 |
예컨대 금융권 모바일 백엔드에서 "프로필 이미지 URL" 입력을 그대로 서버가 내려받는 기능이 있었다면, 공격자는 그 필드에 메타데이터 주소를 넣어 수 초 내에 클라우드 자격증명을 얻을 수 있다. 실제로 이 패턴은 뒤의 사례에서 대규모 유출로 이어졌다.
또 다른 산업 적용 예로, 전자상거래 플랫폼의 상품 등록 기능에서 "외부 상품 이미지 가져오기"를 서버가 수행하는 경우를 들 수 있다. 공격자는 수천 건의 더미 상품을 등록하면서 각 이미지 URL에 내부 IP 대역(http://10.0.0.1~10.0.255.254)을 순차 대입해, 응답 시간 차이만으로 내부망의 살아 있는 호스트와 열린 포트를 지도화(mapping)할 수 있다. 이는 Blind SSRF를 내부 정찰(reconnaissance) 도구로 쓰는 전형이며, 외부 스캔으로는 보이지 않던 내부 구조가 애플리케이션 한 기능을 통해 노출된다는 점에서 위험하다. 버그바운티 생태계에서도 SSRF는 메타데이터 자격증명 탈취로 이어질 수 있어 통상 고등급(High~Critical)으로 보상되는 취약점 유형에 속한다.
5. 비교 — SSRF와 CSRF
이름이 비슷한 CSRF(Cross-Site Request Forgery)와 혼동하기 쉬우나, 둘은 "위조된 요청을 누가 보내는가"에서 본질적으로 다르다. CSRF는 피해자(사용자)의 브라우저가 피해자의 인증 쿠키를 실어 공격자가 원하는 요청을 보내게 만드는 공격으로, 클라이언트 측 신뢰(세션)를 악용한다. 반면 SSRF는 서버 자체가 공격자 대신 요청을 보내므로, 서버의 네트워크 위치와 권한을 악용한다. 따라서 CSRF의 방어는 CSRF 토큰·SameSite 쿠키처럼 "요청 출처 검증"에 집중하지만, SSRF의 방어는 "서버의 송신 대상 제한"에 집중한다. 이 차이를 이해하지 못하면 엉뚱한 대책(예: SSRF에 CSRF 토큰 적용)을 세우게 된다.
이 차이가 실무에서 중요한 이유는 방어 책임의 소재가 다르기 때문이다. CSRF는 주로 애플리케이션 프레임워크 계층(토큰 미들웨어·쿠키 속성)에서 해결되는 반면, SSRF는 애플리케이션 입력 검증만으로는 불완전하고 네트워크·인프라 계층의 egress 통제가 병행되어야 비로소 근본적으로 차단된다. 즉 CSRF가 개발팀의 숙제라면, SSRF는 개발·보안·인프라가 함께 책임지는 "교차 영역" 위협이라는 점이 두 공격의 조직적 함의를 가른다.
또한 피해의 방향성도 대비된다. CSRF는 피해자 개인의 권한 범위 안에서 행위를 도용하므로 피해가 개별 사용자 계정 수준에 머무는 경우가 많다. 반면 SSRF는 서버의 권한을 악용해 인프라 전반(자격증명·내부 서비스)으로 번지므로, 단일 사용자가 아니라 시스템·조직 전체의 기밀성 붕괴로 이어질 수 있다. 바로 이 파급력 차이가 OWASP가 SSRF를 별도 항목으로 승격해 다루게 된 핵심 이유다.
| 구분 | SSRF | CSRF |
|---|---|---|
| 요청 주체 | 서버 | 피해자 브라우저 |
| 악용 신뢰 | 서버의 네트워크 위치·권한 | 사용자 세션·쿠키 |
| 주 피해 | 내부자원 접근·자격증명 탈취 | 사용자 권한 도용 행위 |
| 핵심 방어 | 송신(egress) 통제·allowlist | CSRF 토큰·SameSite |
6. 심화 — 대표 사례와 방어 아키텍처
가장 널리 인용되는 사례는 2019년 Capital One 데이터 유출이다. 공개된 분석에 따르면 공격자는 잘못 설정된 WAF(프록시) 인스턴스를 통해 EC2의 메타데이터 서비스(당시 IMDSv1)에 접근, 인스턴스에 부여된 IAM 역할의 임시 자격증명을 얻어 S3 버킷의 약 1억 건(미국 약 1억·캐나다 약 600만) 규모 고객 정보에 접근했다. 이 사건으로 Capital One은 2020년 미국 통화감독청(OCC)으로부터 약 8천만 달러의 과징금을 부과받았다. 다만 일부 학술 분석은 이를 SSRF가 아닌 개방형 리버스 프록시 악용으로 보기도 하므로, "SSRF의 대표 사례로 널리 인용되나 근본 원인은 프록시·권한 구성 결함"이라고 균형 있게 서술하는 것이 정확하다.
이 사건은 방어 아키텍처를 근본적으로 바꾸는 계기가 되었다. AWS는 2019년 11월 IMDSv2를 도입했는데, 메타데이터 조회 전에 PUT 요청으로 세션 토큰을 먼저 발급받아 이후 요청에 커스텀 헤더(X-aws-ec2-metadata-token)로 실어야 하도록 바꿨다. 단순 GET만 던지는 전형적 SSRF는 이 PUT 선행 단계를 수행하지 못해 차단된다. 또한 메타데이터 응답의 네트워크 홉 수 제한(기본 1)을 두어, 컨테이너·프록시를 거친 요청이 메타데이터에 닿지 못하게 했다. 이는 "애플리케이션 패치"가 아닌 "인프라 기본값 강화"로 문제를 해결한 모범 사례다.
다른 클라우드도 유사한 완화책을 갖는다. GCP와 Azure는 메타데이터 조회 시 각각 Metadata-Flavor: Google, Metadata: true 같은 커스텀 요청 헤더를 필수로 요구한다. 단순한 URL 치환형 SSRF는 이런 헤더를 임의로 붙이기 어려워 일부 차단되지만, 공격자가 헤더까지 제어할 수 있는 경우(예: 요청을 통째로 위조할 수 있는 고도화된 SSRF)에는 우회가 가능하므로, 헤더 요구는 보조 통제일 뿐 근본 대책인 egress 차단을 대체하지 못한다는 점을 설계 시 분명히 인식해야 한다. 이처럼 클라우드마다 세부가 달라, 멀티클라우드 환경에서는 공통의 egress 통제 정책을 중앙에서 일관되게 적용하는 것이 중요하다.
실무 방어는 단일 대책이 아니라 다층 방어(defense-in-depth)로 구성해야 하며, 애플리케이션 계층과 인프라 계층을 반드시 병행한다. 주요 통제는 다음과 같다.
- allowlist 기반 입력 검증: 블랙리스트는 앞서 본 표기 변형·인코딩 우회로 무력화되므로, 허용된 도메인·IP·스킴(
http/https)만 통과시키는 allowlist로 설계한다. URL을 파싱해 실제 접속할 IP를 해석(resolve)한 뒤 사설·링크로컬 대역(RFC 1918의 10/8·172.16/12·192.168/16, 169.254.0.0/16)을 명시적으로 거부한다. - 네트워크 계층 egress 통제(가장 강력): 애플리케이션의 외부 송신을 전용 포워드 프록시로만 보내고, 메타데이터·내부 대역으로의 직접 egress를 방화벽·보안그룹·NetworkPolicy에서 원천 차단한다. 이 통제는 코드 우회 기법과 무관하게 동작하므로 근본 대책에 가깝다.
- 클라우드 메타데이터 강화: IMDSv2 강제, 메타데이터 홉 수 제한(기본 1), 불필요한 인스턴스의 메타데이터 비활성화로 자격증명 조회 경로 자체를 차단한다.
- 최소권한(least privilege): IAM 역할·서비스 계정 권한을 기능에 필요한 최소로 좁혀, 자격증명이 탈취돼도 공격자가 얻는 권한과 피해 범위를 제한한다.
- 리다이렉트·DNS 리바인딩 대비: 외부 요청의
3xx리다이렉트 자동 추적을 끄거나 재검증하고, 검증 시점과 접속 시점의 IP가 달라지는 TOCTOU(리바인딩)를 막기 위해 해석된 IP를 고정(pin)해 연결한다. - 응답 최소화: 가져온 외부 자원의 원문·에러 메시지를 사용자에게 그대로 노출하지 않아 In-band 유출과 반맹목 추론을 줄인다.
탐지·대응 관점도 설계에 포함해야 한다. SSRF는 Blind 유형처럼 응답이 없으면 로그만으로 식별이 어렵기 때문에, "애플리케이션 서버가 내부 대역·메타데이터 엔드포인트로 비정상 송신을 시도한 이벤트"를 egress 프록시·방화벽 로그에서 상관분석(correlation)해 SIEM으로 경보화하는 것이 효과적이다. 특히 169.254.169.254 로의 접근 시도는 정상 애플리케이션 트래픽에서는 거의 발생하지 않으므로 고신뢰 탐지 시그니처로 활용할 수 있다. 침투테스트 시에는 외부 콜백 수집 서버를 이용해 Blind SSRF까지 능동적으로 검증해야 한다.
표준·프레임워크 측면에서 SSRF는 CWE-918(Server-Side Request Forgery)로 분류되며, OWASP는 테스트 가이드와 치트시트를 통해 allowlist·IP 검증·스킴 제한 등의 구체적 점검 항목을 제시한다. 조직은 이들을 자사 보안 코딩 표준과 코드리뷰 체크리스트에 반영하고, 신규 기능 설계 단계의 위협 모델링에서 "외부 URL을 서버가 취득하는가"를 필수 질문으로 삼아, 사후 패치가 아닌 사전 설계로 위험을 통제하는 것이 바람직하다.
7. 고려사항 및 시사점 (기술사 관점)
SSRF는 "한 줄짜리 입력 검증 버그"로 축소해 보면 번번이 재발하는 반면, 신뢰 경계와 네트워크 토폴로지의 문제로 격상해 보면 체계적으로 통제할 수 있다. 정보관리기술사 관점에서는 다음 다섯 가지를 균형 있게 고려해야 한다.
- 적용 전략: SSRF는 단일 코드 수정이 아니라 신뢰 경계 재설계로 접근해야 한다. 외부 URL을 서버가 가져오는 모든 기능(웹훅·임포터·프리뷰)을 자산으로 식별하고, 각 기능에 allowlist와 전용 송신 프록시를 적용하는 "보안 설계 by default" 체계를 수립한다.
- 트레이드오프: 엄격한 allowlist·egress 차단은 보안을 높이지만 정당한 외부 연동의 유연성을 떨어뜨린다. 반대로 편의를 위해 임의 URL을 허용하면 공격면이 커진다. 조직은 기능별 위험도에 따라 "허용 범위 대 운영 민첩성"의 균형점을 정책으로 명문화해야 한다.
- 전망: 서버리스·컨테이너·서비스 메시 확산으로 내부 통신이 기하급수적으로 늘면서 SSRF의 공격면도 커진다. 클라우드 제공자의 메타데이터 기본값 강화(IMDSv2 강제)와 더불어, 워크로드 아이덴티티(워크로드별 단명 토큰)와 제로트러스트 기반의 송신 통제가 표준이 될 전망이다.
- 연계 기술: SSRF 방어는 제로트러스트(ZTNA), 네트워크 분할(마이크로세그멘테이션), 워크로드 아이덴티티(SPIFFE/SPIRE), 클라우드 보안 형상관리(CSPM)와 긴밀히 연계된다. 특히 egress 통제는 데이터 유출 방지(DLP)와 함께 설계할 때 효과가 극대화된다.
- 거버넌스: SSRF는 개발·보안·인프라 책임이 교차하는 영역이므로, SSDLC상의 위협 모델링과 코드 리뷰 체크리스트에 "외부 URL 취득 기능" 항목을 상시 포함하고, 침투테스트 시나리오에 Blind SSRF 탐지를 반드시 넣어야 한다.
- 공급망·서드파티 고려: 직접 작성한 코드뿐 아니라 이미지 처리 라이브러리, PDF 생성기, 문서 변환기, 헤드리스 브라우저 같은 서드파티 컴포넌트도 내부적으로 URL을 가져오면 SSRF 경로가 될 수 있다. 따라서 의존성 인벤토리(SBOM)에 "외부 요청을 수행하는 컴포넌트"를 식별하고, 이들도 egress 통제의 대상 안에 두어야 한다.
- 측정과 개선: SSRF 대응의 성숙도는 "allowlist 적용 기능 비율", "egress 차단 커버리지", "IMDSv2 강제율" 같은 정량 지표로 관리하고, 레드팀 훈련 결과를 피드백해 지속적으로 통제를 보강하는 PDCA 체계를 갖추는 것이 바람직하다.
참고자료
- OWASP Top 10 2021, A10:2021 – Server-Side Request Forgery (SSRF): https://owasp.org/Top10/2021/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
- Capital One Data Breach (2019) 분석 (CloudSEK): https://www.cloudsek.com/knowledge-base/capital-one-data-breach
- AWS, Instance Metadata Service Version 2(IMDSv2): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
- OWASP Cheat Sheet, Server-Side Request Forgery Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
- MITRE, CWE-918: Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
한 줄 요약: SSRF는 신뢰된 서버를 공격자의 대리 요청기로 만들어 내부망·클라우드 메타데이터에 닿게 하는 아키텍처 결함으로, 블랙리스트가 아닌 allowlist·egress 통제·최소권한·IMDSv2 같은 다층·인프라 기본값 방어로 대응해야 한다.