487. SSRF (Server-Side Request Forgery) - 서버 측 요청 위조

핵심 인사이트 (3줄 요약)

본질: SSRF(서버 사이드 요청 위조)는 해커가 밖에서 방화벽을 뚫지 않고, 우리 회사 내부망(DMZ)에 있는 웹 서버에게 "야, 너 사내망에 있는 DB 서버나 클라우드 메타데이터 주소(169.254.169.254)로 대신 접속해서 나한테 결과 좀 갖다줘!"라고 악성 URL을 던져 대신 심부름(위조)을 시키는 해킹 기법이다.

가치: 클라우드(AWS, Azure) 시대와 웹훅(Webhook) API의 팽창으로 2021년 OWASP Top 10에 새롭게(10위) 진입했다. 방화벽 안쪽에 있어서 절대 털리지 않는다고 믿었던 내부 서버들조차, '문지기(웹 서버)가 배신자(좀비)로 돌변하여 내부망을 폭격하는' 제로 트러스트(Zero Trust)의 절대적 필요성을 입증하는 치명적 취약점이다.

융합: 사용자 입력값(URL)에 대한 철저한 화이트리스트(Whitelist) 검증은 물론이고, 클라우드 환경에서는 IMDSv2(클라우드 토큰 인증 강제화) 도입, 내부망 서버 간의 네트워크 분리(Network Segmentation) 아키텍처와 융합되어 심층 방어(Defense in Depth)를 완성한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: CSRF(Client-Side Request Forgery)가 사용자의 브라우저를 속여서 클릭하게 만드는 거라면, SSRF는 '서버(Server)' 자체를 해커의 꼭두각시(프록시)로 속여서 조종하는 것이다. 이미지 번역 사이트에서 "번역할 이미지 URL을 넣으세요" 칸에, 해커가 사진 주소 대신 http://localhost:3306(서버 자기 자신의 내부 DB 주소) 나 http://192.168.0.5(사내망 깃허브 서버)를 넣는다. 웹 서버는 순진하게 "오케이, 그 주소로 가서 다운받아 올게!"라며 밖(인터넷)에서는 절대 못 들어가는 내부망의 알몸 데이터를 싹 다 긁어서 해커에게 뱉어준다.
필요성: 옛날에는 해커가 해킹하려면 1차로 웹 서버를 뚫어 권한을 탈취(RCE)한 뒤에야, 그 서버를 밟고 내부망으로 들어갔다. 그런데 현대의 앱들은 타사 API(결제, 날씨), 웹훅(Slack 알림) 등 서버가 직접 밖으로 URL을 찔러서 데이터를 가져오는 기능이 떡칠 되어 있다. 해커 입장에선 굳이 웹 서버 권한을 딸 필요도 없다. 그냥 그 URL 입력창에 "내가 원하는 사내망 주소"만 던지면 웹 서버가 친절하게 다 긁어다 바치기 때문이다. 이 허무한 하이패스(프리패스)를 틀어막기 위해 SSRF 방어 아키텍처가 급부상했다.
💡 비유: SSRF는 **'택배 기사를 심부름꾼으로 악용하는 도둑'**과 같습니다. 도둑(해커)은 부잣집 대문(방화벽)을 직접 뚫을 수 없습니다. 그래서 부잣집 문 앞에 배달 온 택배 기사(웹 서버)에게 쪽지를 건넵니다. "기사님, 저기 안방(내부망 DB)에 들어가서 금고 좀 열어오라는 게 주인님 명령(위조된 URL)이에요!" 기사님은 아무 의심 없이 안방 문을 엽니다. 경비견(내부 방화벽)은 택배 기사를 한 식구(내부자)로 알고 짖지 않습니다. 도둑은 손가락 하나 까딱 안 하고 금고를 털어갑니다.
등장 배경 및 발전 과정:
1. CSRF의 유행과 쇠퇴: 과거엔 해커들이 클라이언트(브라우저)를 속이는 CSRF에 미쳐있었다. 그러나 브라우저 벤더들이 SameSite 쿠키 정책을 강제하며 CSRF는 멸종 위기에 처했다.
2. 클라우드의 등장 (메타데이터 털기): 해커들이 타겟을 서버로 돌렸다. 특히 AWS EC2 인스턴스 내부에 존재하는 마법의 IP(169.254.169.254)를 SSRF로 찌르면, EC2에 부여된 **최고 관리자 탈취 키(IAM Token)**가 평문으로 줄줄 쏟아져 나온다는 사실이 발견되며 전 세계 클라우드가 발칵 뒤집혔다 (2019년 캐피털 원(Capital One) 해킹 사태).
3. OWASP Top 10 신규 진입 (2021): 클라우드 파멸의 주범으로 찍히며 당당히 10위로 신설 진입, "서버 밖으로 나가는 모든 URL 호출(Outbound)을 통제하라"는 새로운 시대정신을 알렸다.
📢 섹션 요약 비유: 해커가 성벽 밖에서 돌을 던지는 게 아니라, 성문 앞에 서 있는 경비병(웹 서버)에게 최면(SSRF)을 걸어 "가서 너네 왕의 목을 따오라"고 조종하는 가장 악랄하고 완벽한 내부자 공격의 우회술입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. SSRF 3대 공격 시나리오 (해커가 쏘는 타겟)

웹 서버를 좀비로 만든 해커는 도대체 '어딜' 찌르라고 명령하는가?

클라우드 메타데이터 탈취 (AWS IMDS 공격)
- 공격: URL 입력창에 http://169.254.169.254/latest/meta-data/iam/security-credentials/ 입력.
- 결과: 서버(EC2)가 자기 자신(아마존 비밀 주소)에게 요청을 보내어, 임시 접근 토큰(Access Key)을 해커 화면에 뱉어낸다. 해커는 이 키로 AWS S3 버킷과 DB를 싹 다 포맷해 버린다.
사내망(Intranet) 스캐닝 및 백도어 오픈
- 공격: http://192.168.0.1:8080, http://192.168.0.2:22 처럼 끝자리만 바꿔가며 계속 찌른다.
- 결과: 외부에서는 막혀있는 사내 Redis, Elasticsearch 서버들이 "같은 망 식구(웹 서버)가 찌르니까 열어주네?"라며 무혈입성 당한다.
내부 서버 자체 파일 유출 (File URI Scheme)
- 공격: http:// 대신 file:///etc/passwd 라고 적어 보낸다.
- 결과: 서버 내부의 HTTP 라이브러리가 "어? 파일 읽으라고?" 하며 리눅스 커널의 최고 기밀 파일(패스워드)을 화면에 찍어준다 (Local File Inclusion 융합).

2. SSRF 절대 방어 아키텍처: 화이트리스트와 DMZ 고립

해커의 창(SSRF)을 막으려면 코드 레벨과 인프라 레벨의 양면 방어가 필수다.

[ 해커의 악성 URL 요청 (http://169.254.169.254) ]
           ▼
[ 1단계 코드 방어 (Whitelist Validation) ]
  - "이봐, 클라이언트가 던진 도메인이 우리가 허락한 `*.weather.com` 이 맞아?"
  - IP 파싱: "혹시 도메인을 `http://localhost`나 `127.0.0.1`로 교묘하게 변조했어? 꺼져!"
           ▼ (통과한 순수한 URL만 실행)
[ 웹 서버 (HTTP Client) ]
           ▼
[ 2단계 인프라 방어 (Network Egress Control) ]
  - 웹 서버가 속한 서브넷(DMZ)의 라우터 방화벽:
  - "이 웹 서버는 외부의 `weather.com` 포트만 찌를 수 있고, 
     내부망(192.168.x.x)이나 AWS 비밀 주소(169.x.x.x)로 향하는 모든 통신(Egress)은 무조건 DROP(폐기)한다!"

📢 섹션 요약 비유: 이 2단 방어는 **'경비병 세뇌 방어 훈련'**과 같습니다. 경비병(웹 서버) 귀에 귀마개(화이트리스트 필터)를 씌워서 주인이 허락한 명령(허락된 도메인) 말고는 아예 듣지 못하게 막습니다(1차 방어). 설령 최면에 걸려서 움직이더라도, 경비병의 발목에 쇠사슬(인프라 아웃바운드 방화벽)을 묶어놔서 안방(내부망) 쪽으로는 절대 한 발자국도 걸어갈 수 없게 물리적으로 묶어두는(2차 방어) 완벽한 통제입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. SSRF (서버 사이드) vs CSRF (클라이언트 사이드)

이름은 비슷하지만 해커가 '누구'를 꼭두각시로 조종하느냐가 정반대다.

척도	SSRF (Server-Side Request Forgery)	CSRF (Cross-Site Request Forgery)
꼭두각시(좀비)	우리 회사 '웹 서버'	내 사이트에 접속한 '사용자의 브라우저'
공격 원리	해커 ➡ 웹 서버 조종 ➡ 내부망(DB) 폭격	해커 ➡ 사용자 조종 ➡ 웹 서버에 강제 결제 요청
탈취/이용 수단	서버가 가진 내부망 접속 권한(VPC, IAM)	브라우저에 저장된 사용자의 쿠키(Session) 권한
방어 아키텍처	도메인 화이트리스트(Whitelist) 검증, 아웃바운드 망 분리	CSRF Token 삽입, `SameSite=Strict` 쿠키 정책
현재 위상	2021 OWASP 신규 10위 (가장 뜨는 위협)	브라우저 방어 기술 발전으로 10위권 밖으로 밀려남

과목 융합 관점

클라우드 컴퓨팅 (IMDSv2의 구원): AWS는 SSRF 때문에 에퀴팩스가 털린 것에 충격을 받고, 메타데이터 서비스(IMDS) 구조를 뜯어고쳤다. 과거엔 그냥 주소만 치면 토큰을 줬다(v1). 이제는 IMDSv2를 강제하여, 토큰을 달라고 찌를 때 무조건 HTTP PUT으로 헤더에 비밀번호를 넣고 세션을 연 다음에만 토큰을 주도록 아키텍처를 진화시켰다. 멍청한 SSRF 공격 패킷(단순 GET 요청)으로는 절대 뚫을 수 없는 클라우드 레벨의 궁극적 면역 체계가 완성되었다.
네트워크 (제로 트러스트와 마이크로 세그멘테이션): 과거엔 "DMZ(웹) ➡ 내부망(DB)" 방화벽 정책을 "내부 통신이니까 다 열어둬!"라고 대충 짰다(SSRF의 밥). 제로 트러스트(Zero Trust) 사상이 융합되며, 이제는 네트워크를 바둑판처럼 갈기갈기 찢는 **마이크로 세그멘테이션(Micro-segmentation)**이 대세다. 웹 서버 A는 오직 DB 서버 A의 3306 포트만 찌를 수 있고, 옆에 있는 캐시 서버 B는 절대 못 찌르게 서브넷과 보안 그룹(Security Group)을 핀셋으로 도려내어 SSRF가 터져도 해커가 횡적 이동(Lateral Movement)을 못 하고 독방에 갇혀 죽게 만든다.
📢 섹션 요약 비유: CSRF는 도둑이 내 손을 억지로 끌어다가 지문 인식기에 대서 내 집 문을 여는 것(클라이언트 조종)입니다. SSRF는 도둑이 내 집 안에 있는 로봇 청소기(서버)를 조종해서, 금고 열쇠를 줍게 한 다음 창밖으로 던지게 만드는(서버 조종) 고도의 원격 지휘 해킹입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 웹훅(Webhook) 기능이 빚어낸 사내망 전멸의 비극: 슬랙(Slack)처럼 "게시글이 달리면 고객님이 설정한 URL로 핑(Ping)을 쏴드릴게요!"라는 웹훅 기능을 만들었다. 해커가 웹훅 URL에 http://192.168.1.5:9200 (사내 Elasticsearch 디버그 포트)를 넣었다. 게시글이 달릴 때마다 우리 웹 서버는 친절하게 저 주소로 POST 요청을 날렸다. 문제는 엘라스틱서치가 REST API로 돌아가는 DB라, POST 바디에 들어있는 텍스트를 인젝션 명령어로 인식해서 DB 테이블 전체를 날려버리는 파멸을 맞았다.
- 아키텍트의 해결책: 아웃바운드(Egress) 통제 불능이 낳은 대참사다. 웹훅이나 썸네일 생성처럼 외부 URL을 대신 찔러줘야 하는 서비스는 SSRF의 거대한 지뢰밭이다. 아키텍트는 이런 위험한 통신을 메인 웹 서버에서 절대 쌩으로 돌리면 안 된다. 메인 서버는 큐(Kafka)에 URL만 띡 던지고 끝낸다. 뒷단에 있는 격리된 람다(AWS Lambda)나 전용 Proxy 프록시 서버가 큐에서 URL을 꺼내 대신 찔러주도록 해야 한다. 이 프록시 서버는 사내망(192.168.x.x)에 절대 접근할 수 없는 깡통 서브넷에 가두어, 해커가 이 서버를 1만 번 조종해도 사내 DB 근처에도 못 가게 아키텍처를 분리(Decoupling)시켜야 한다.
시나리오 — 블랙리스트 필터링의 우회(Bypass) 꼼수에 당한 멍청한 코드: 개발자가 SSRF 방어를 한답시고 로직을 짰다. if (url.contains("localhost") || url.contains("169.254")) { return error; }. 해커가 콧방귀를 뀌며 URL에 http://2130706433 (127.0.0.1의 10진수 변환) 또는 http://127.0.0.1.nip.io (무조건 로컬호스트로 매핑되는 DNS)를 날렸다. 멍청한 필터는 "오, 로컬호스트라는 글씨가 없네?"라며 통과시켰고, 서버 OS 단의 HTTP 라이브러리가 이 주소를 똑똑하게 로컬호스트로 해석해서 내부망을 다 털어버렸다.
- 아키텍트의 해결책: 개발자의 정규식(블랙리스트) 맹신이 부른 참사다. IP 주소와 도메인을 가리는 우회 기법은 10만 가지가 넘는다. 인간이 정규식으로 막는 것은 불가능하다. 아키텍트는 "나쁜 놈을 잡지 말고, 착한 놈만 들여보내라(Whitelist)"는 절대 명제를 수호해야 한다. DNS 리졸빙(Resolving)을 끝내서 최종 IP를 뽑아낸 다음에, 그 IP 대역이 사설망(Private IP: 10.0.x.x, 172.16.x.x 등)인지 검사하는 시스템 레벨의 라이브러리(SSRF-Filter 등)를 강제 적용해야 바보 같은 우회 공격을 원천 봉쇄할 수 있다.

도입 체크리스트

기술적: HTTP Redirect(301/302) 자동 따라가기를 허용해 두었는가? 1차 화이트리스트 방어를 뚫는 해커의 필살기다. 해커가 http://hacker.com (정상 외부 사이트로 보임)을 입력한다. 방어벽은 통과시킨다. 그런데 서버가 저 사이트를 찔렀더니, 해커 사이트가 Location: http://169.254.169.254 로 301 리다이렉트 응답을 뱉는다. 자바의 HttpURLConnection은 눈치 없이 "오, 절로 가라고?" 하며 스스로 구멍 속으로 다이빙(SSRF)해 버린다. HTTP 클라이언트 옵션에서 **"리다이렉트 자동 수행 옵션(Follow Redirects)을 무조건 끄거나(False), 꺾이는 2차 주소도 한 번 더 검사하게 룰을 짤 것"**이 면접 단골 질문이자 필수 방어책이다.
인프라적: 클라우드 메타데이터 토큰 버전을 강제 업그레이드했는가? AWS를 쓴다면 EC2 설정에 들어가서 IMDSv1 옵션을 싹 다 죽여버리고, 무조건 세션 키가 필요한 IMDSv2 Required 모드로 올렸는지 테라폼(Terraform) 인프라 코드 레벨에서 린터(Linter)로 멱살 잡고 검사해야 클라우드 전멸을 막을 수 있다.

안티패턴

"프론트엔드에서 도메인 유효성 꼼꼼하게 검사함!" (가짜 방어): 100번 말하지만 프론트(JS)에서 막는 건 해커에게 아무 의미가 없다. 해커는 브라우저를 끄고 리눅스 쉘에서 curl 명령어로 백엔드 API에 직접 사내망 URL을 날린다. 프론트엔드의 방어는 선량한 사용자의 오타를 막는 편의 기능일 뿐, 해커를 막는 방패는 오직 백엔드 컨트롤러 1줄짜리 인터셉터 필터 안에 콘크리트로 박혀있어야 한다.
📢 섹션 요약 비유: 리다이렉트를 허용하는 것은, **'경비원에게 착한 손님만 들여보내라고 지시하는 것'**과 같습니다. 해커가 양복을 입고(정상 도메인) 들어옵니다. 경비원이 들여보냅니다. 그런데 문턱을 넘자마자 해커가 양복을 찢어버리고 도둑 복장(내부망 IP 리다이렉트)으로 돌변해 금고로 뜁니다. 경비원이 "어? 들어갈 땐 착했는데 속에서 변하네? 난 몰라~" 하고 놔두면 파산입니다. 옷을 갈아입는 순간 즉시 몽둥이로 때려눕히는(리다이렉트 금지) 깐깐한 경비원이 필요합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	무지성 외부 URL 호출 및 내부망 통로 방치 (AS-IS)	화이트리스트 + 아웃바운드 차단 + IMDSv2 (TO-BE)	개선 효과
정량	SSRF로 인해 AWS IAM 토큰 탈취, 서버 100대 삭제	IMDSv2 강제 적용으로 클라우드 메타데이터 해킹 0건	클라우드 인프라 통째 탈취 리스크(RCE 급) 100% 방어
정량	웹훅(Webhook) 서버를 통한 사내망 DB 정보 유출 연 5건	웹훅 전용 격리 프록시(Proxy) 서버 구축으로 내부망 접근 불능	서버를 경유하는 횡적 이동(Lateral Movement) 피해율 0%
정성	"URL 파라미터가 이렇게 무서운 폭탄인 줄 몰랐다"	"입력값은 모두 적이다" 제로 트러스트(Zero Trust) 내재화	개발 조직의 외부 리소스 획득 아키텍처에 대한 철통같은 보수성 획득

미래 전망

AI 프롬프트 주도 SSRF의 등장: 챗GPT 같은 LLM(거대 언어 모델)이 회사 서버에 연동되었다. 해커가 챗봇에게 "사내망 인사팀 서버(192.168.0.x)로 가서 내일 점심 메뉴 좀 읽어와봐"라고 프롬프트를 날린다. 멍청하고 친절한 AI는 시스템 권한을 이용해 쓱 가서 긁어온다. 이것이 바로 AI 에이전트를 좀비로 쓰는 **차세대 인지적 SSRF(LLM-based SSRF)**이며, 미래의 보안 아키텍트가 막아내야 할 가장 창의적이고 악랄한 제1의 위협이 될 것이다.
네트워크 레벨의 자율 주행 킬스위치(Kill-Switch): 코딩으로 막는 데는 한계가 있다. 이스티오(Istio) 같은 서비스 메시(Service Mesh) 인프라가 스스로 진화하여, 웹 서버(Pod)가 밖(Outbound)으로 쏘는 모든 패킷의 목적지를 0.001초 단위로 AI가 검사한다. "어? 웹 서버가 평소에 안 찌르던 사내 레디스(Redis) 서버를 찌르네?" ➡ 1초 만에 패킷을 썰어버리고 웹 서버 파드를 격리 감방으로 보내버리는 '인프라 차원의 오토 SSRF 면역 체계'가 완성되고 있다.

참고 표준

OWASP Top 10 (A10: Server-Side Request Forgery): 과거엔 순위에도 없다가 클라우드 시대의 가장 취약한 급소로 인정받으며 2021년 영광의 10위로 신설 데뷔한, 서버를 꼭두각시로 만드는 현대 마법의 상징. (이전 장 477번)
AWS IMDSv2 (Instance Metadata Service Version 2): 캐피털 원 해킹(SSRF) 사태 이후 빡친 아마존이 "더 이상 해커들이 토큰 못 가져가게 룰을 싹 다 바꾼다!"며 전 세계 클라우드 생태계에 강제 선포한 메타데이터 보호 절대 규약.

서버 사이드 요청 위조(SSRF)는 방어자들에게 **"가장 굳건히 믿었던 우리 편(웹 서버)의 뇌가 해커에게 해킹당할 때의 공포"**를 가르쳐 준다. 우리는 성벽(방화벽) 밖의 적군만 쳐다보느라, 성안을 돌아다니는 아군 전령(서버)이 해커의 거짓 명령서(위조된 URL)에 홀려 금고 문을 직접 열어버리는 이 허무한 배신을 짐작하지 못했다. 기술사는 아무리 우리 팀이 만든 서버라도 무조건적인 신뢰를 보내서는 안 된다. 서버가 내뻗는 모든 손길(아웃바운드 트래픽)에 의심의 족쇄(화이트리스트)를 채우고, 눈이 멀어 벼랑(내부망)으로 뛰어들려 할 때 목줄을 확 잡아당기는 차가운 인프라 설계(네트워크 격리), 그것만이 제로 트러스트(Zero Trust) 시대에 내 집을 지키는 가장 비정하고도 완벽한 통제술이다.

📢 섹션 요약 비유: SSRF를 막는 아키텍처는 **'청와대 비서실장의 문서 결재 필터링'**과 같습니다. 대통령(웹 서버)은 엄청난 권한을 가졌지만 너무 바빠서 남이 주는 서류(URL)를 그냥 읽고 사인해 버립니다. 해커가 "금고 열기" 서류를 결재판에 몰래 끼워 넣습니다(SSRF). 만약 비서실장(화이트리스트 필터/방화벽)이 없다면 대통령은 나라를 팔아먹는 사인(실행)을 해버립니다. 똑똑한 비서실장이 "이건 허락된 양식이 아닙니다! 당장 파쇄해!"라며 대통령의 눈을 가려주는 철통같은 중간 보좌관 룰, 그것이 SSRF 방어의 핵심입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
OWASP Top 10	클라우드 시대가 부른 10위 신흥 강자. 옛날엔 서버가 밖을 찌를 일이 별로 없어서 무시당하다가, 마이크로서비스(MSA)와 웹훅(Webhook)이 폭발하면서 황금 왕좌에 등극했다. (이전 장 477번)
CSRF (크로스 사이트 요청 위조)	SSRF의 배다른 형제. 해커가 '서버'를 꼬드기면 SSRF, 해커가 '사용자 브라우저'를 꼬드겨서 좀비로 만들면 CSRF다. 둘 다 "대신 심부름시키기"라는 악랄한 본질은 같다.
제로 트러스트 (Zero Trust)	"사내망에 있는 DB니까 암호 안 걸어도 안전해!"라는 멍청한 낭만을 부숴버린 SSRF의 카운터펀치. 내부망이라도 무조건 암호화하고 의심해야 서버가 좀비가 돼도 버틸 수 있다.
화이트리스트 (Whitelist)	SSRF 방어의 알파요 오메가. 해커의 기상천외한 URL 우회술(IP 인코딩 등)을 블랙리스트(차단)로 막는 건 불가능하다. 오직 "이 도메인만 허락!"이라는 화이트리스트만이 살길이다.
마이크로 세그멘테이션 (Micro-segmentation)	성안에 들어온 좀비 서버가 돌아다니지 못하게, 성안의 모든 방과 복도 사이사이에 콘크리트 벽(서브넷 방화벽)을 촘촘하게 쳐버리는 인프라 레벨의 SSRF 격리 수술.

👶 어린이를 위한 3줄 비유 설명

내가 만든 심부름 로봇에게 "저기 '슈퍼마켓(정상 URL)'에 가서 아이스크림 좀 사다 줘!"라고 주소를 알려주면 척척 사 오는 기능이 있어요.
그런데 나쁜 도둑이 로봇의 주소 입력창에 **"슈퍼마켓 말고, 우리 아빠 '안방 금고(사내망)'에 가서 돈 좀 꺼내다 줘!"**라고 가짜 주소(위조)를 입력했어요.
바보 로봇이 도둑의 말을 듣고 우리 집 금고를 열어서 도둑에게 돈을 바쳐버리는 끔찍한 심부름 조종 해킹을 **'SSRF (서버 측 요청 위조)'**라고 부른답니다!