같은 SSRF인데 하나는 진짜, 하나는 조건부 — 무엇이 가르나
같은 SSRF인데 하나는 진짜, 하나는 조건부 — 무엇이 가르나
분류: Security · 검증방법론 · SSRF 트리아지 [정보성]
덱. 서버가 공격자 지정 URL로 요청을 보내게 만드는 SSRF(서버 사이드 요청 위조)는 코드만 보면 다 똑같아 보입니다. 그런데 같은 모양의 결함이라도 그 값이 어디서 들어오는지에 따라 실제 위험도가 크게 갈립니다. 이 글은 저희가 검증 작업을 반복하며 정리한, SSRF의 진짜/가짜를 가르는 기준 하나를 소개합니다.
리드
취약점 헌팅에서 흔한 실수 중 하나는 “이 값이 URL로 흘러가고, 그 URL로 서버가 요청을 보낸다”는 사실 하나만으로 SSRF를 확정 짓는 것입니다. 이 조건은 필요하지만 충분하지 않습니다. 그 값이 공격자가 요청 한 번으로 직접 밀어넣을 수 있는 값인지, 아니면 관리자·개발자가 미리 설정해 둬야만 존재하는 값인지를 구분하지 않으면, 실제로는 별다른 위험이 없는 결함을 심각한 취약점으로 잘못 보고하게 됩니다.
핵심 사실 요약
- SSRF는 서버가 사용자 대신 외부(또는 내부) 자원에 HTTP 요청을 보내는 기능이 있을 때, 그 요청 대상 URL을 공격자가 통제할 수 있으면 발생합니다. 대표적 피해는 클라우드 메타데이터 서버 접근, 내부망 스캐닝, 방화벽 우회입니다. 이 개념 자체는 OWASP·PortSwigger 등에서 오래 정리된 표준 취약점 클래스입니다.
- 코드를 볼 때 SSRF 소지를 판단하는 첫 단서는 “IP·스킴 검증 없이 사용자 통제 값을 그대로 HTTP 클라이언트에 넘기는가”입니다. 여기까지는 정적 분석만으로도 확인할 수 있습니다.
- 그런데 실제 위험도를 가르는 것은 그 값이 들어오는 시점입니다. 저희는 이를 “요청 시점(request-time)“과 “설정 시점(config-time)” 두 갈래로 나눠 봅니다.
- 요청 시점 유입: 공격자가 보내는 HTTP 요청의 본문·쿼리스트링 같은 값이 곧바로 SSRF sink로 흘러갑니다. 이 경우는 별도 전제 조건 없이 공격자가 요청 한 번으로 트리거할 수 있으므로, 실제로 강한 취약점입니다.
- 설정 시점 유입: 값이 관리자나 개발자가 미리 등록해 둔 설정·스펙(예: 외부에서 불러온 OpenAPI 정의, OIDC 설정의 issuer URL 같은 필드)에서 옵니다. 이 경우 공격자가 이 결함을 실제로 쓰려면 그 설정 자체를 먼저 조작할 수 있어야 합니다.
- 두 번째 경우의 함정은, “설정을 조작할 수 있다”는 전제가 이미 그 자체로 별개의 심각한 취약점(설정 주입)이라는 점입니다. 공격자가 이미 시스템이 불러오는 스펙·설정 파일을 바꿀 수 있다면, SSRF는 그 상황에서 나오는 부수 효과 중 하나일 뿐이지, 독립적으로 성립하는 “인증 없는 SSRF”라고 보고하기는 어렵습니다.
- 그래서 저희가 검증에 쓰는 실무 규칙은 이렇습니다 — 의심되는 SSRF sink마다, 그 입력값의 유입 경로를 요청 본문/쿼리(요청 시점)까지 거슬러 올라가 확인한 뒤에만 심각도를 매긴다. 설정 시점에서만 트리거되는 sink는 방어 심화(hardening) 관점의 권고 사항으로 남기되, 별도 전제 없이 성립하는 강한 취약점으로 분류하지 않습니다.
- 이 구분은 SSRF에만 해당하지 않습니다. 경로 순회(path traversal), 커맨드 인젝션 같은 다른 클래스에서도 “정적으로는 그럴듯해 보이지만 실제로 그 입력에 도달하는 경로가 공격자 손이 닿지 않는 곳”이면 같은 논리로 등급을 낮춰야 합니다.
짧은 논평
이 기준은 저희가 “취약점처럼 보인다”와 “실제로 취약하다”를 가르는 데 반복적으로 쓰는 검증 원칙 중 하나입니다. 정적 분석은 “이 코드 경로가 위험한 동작을 한다”까지는 잘 잡아내지만, “그 위험한 동작에 공격자가 실제로 손을 뻗을 수 있는가”는 별도로 확인해야 합니다. 저희는 이 둘을 분리해서 보는 습관이, 과대평가된 취약점 신고를 줄이고 진짜 위험에 검증 자원을 집중시키는 데 가장 효과적이라고 봅니다.
References / 참고자료
- PortSwigger Web Security Academy, “Server-side request forgery (SSRF)” — SSRF의 기본 개념·공격 패턴 정리. https://portswigger.net/web-security/ssrf
- OWASP, “Server Side Request Forgery” — SSRF 클래스의 표준 정의와 방어 원칙. https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
이 글은 저희가 실제 검증 작업에서 반복적으로 마주친 패턴을 일반화해 정리한 정보성 글입니다. 특정 제품·조직·프로그램명은 담지 않았으며, 인용한 자료의 문장을 그대로 옮기지 않았습니다.