SSRF (Server-Side Request Forgery): 서버가 대신 요청하게 만들기

SSRF는 서버가 사용자 입력으로 받은 URL로 자체적으로 요청을 보내는 기능을 악용해서, 원래는 외부에서 접근 못 하는 내부망 리소스에 접근하는 공격이다. URL 미리보기, 웹훅 등록, 이미지/PDF 렌더링, "URL로 가져오기" 같은 기능에서 자주 나온다.

원리

POST /api/fetch-preview
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }

서버가 이 URL로 그대로 요청을 보내면, 클라우드 인스턴스의 메타데이터 엔드포인트(AWS/GCP/Azure 공통 패턴)에서 임시 자격증명을 통째로 가져올 수 있다. 이게 SSRF가 다른 취약점보다 위험도가 높게 평가되는 이유 — 성공하면 바로 클라우드 계정 권한 탈취로 이어지는 경우가 많다.

그 외에도:

• http://localhost:6379 같은 내부 전용 서비스(Redis, 관리자 패널, 내부 API)에 접근
• file:///etc/passwd 같은 스킴으로 로컬 파일 읽기 (파서가 file://을 허용하는 경우)
• 포트 스캔처럼 내부망 구조를 응답 시간/에러 차이로 매핑

탐지 방법

1. URL을 입력받는 기능을 모두 찾는다 (미리보기, 웹훅, 아바타 URL 업로드, PDF 변환 등)
2. 우선 자신이 통제하는 서버(예: requestbin, 직접 띄운 HTTP 리스너)로 요청을 유도해서 SSRF 자체가 성립하는지 확인
3. 성립하면 http://169.254.169.254/..., http://localhost:<내부포트>, http://127.0.0.1, 10.x/172.16.x/192.168.x 내부 대역으로 확장
4. IP 필터링이 있다면 우회 시도: http://0177.0.0.1(8진수), http://2130706433(정수 표현), DNS 리바인딩, 리다이렉트 체인(http://attacker.com → 302 → 내부 주소)

방어

• 화이트리스트 기반으로 요청 가능한 호스트/스킴을 제한한다. 블랙리스트(사설 IP 대역 차단)는 인코딩·리다이렉트로 우회당하는 경우가 많다.
• 내부 요청용 라이브러리에서 리다이렉트를 자동으로 따라가지 않도록 설정하거나, 리다이렉트 목적지도 매번 재검증한다.
• 클라우드 메타데이터 엔드포인트는 IMDSv2(토큰 기반, 단순 GET으로 못 가져오게) 같은 최신 방식으로 전환한다.
• 가능하면 이 기능을 처리하는 서버 자체를 내부망 접근 권한이 없는 별도 네트워크 세그먼트에 둔다.