서버측 요청 위조

서버측 요청 위조 (API7: Server Side Request Forgery, SSRF)

API가 사용자가 준 URL이 맞는지 검증하지 않고 그대로 원격 자원을 가져오면 서버측 요청 위조(SSRF) 가 발생해요. 공격자가 조작한 요청을 애플리케이션이 대신 보내도록 만들어, 방화벽이나 VPN으로 보호된 내부망까지 접근하게 만드는 공격이에요. 현대 개발 문화가 사용자 입력 기반의 외부 자원 접근(웹훅, URL에서 파일 가져오기, 커스텀 SSO, URL 미리보기)을 장려하면서 흔해졌고, 클라우드·Kubernetes·Docker의 관리 채널이 HTTP 위에서 예측 가능한 경로로 노출되면서 더욱 위험해졌어요.

출처: OWASP API Security Top 10 — API7:2023 Server Side Request Forgery

어떤 API가 취약한가요?

API가 사용자가 공급한 URL을 검증하지 않고 원격 자원을 가져올 때 SSRF가 발생해요. 특히 응답이 공격자에게 돌아오는 일반 SSRF보다, 응답이 돌아오지 않아 성공 여부를 알 수 없는 Blind SSRF가 탐지하기가 훨씬 까다로워요. 성공적으로 악용되면 내부 서비스 열거(포트 스캔), 정보 노출, 방화벽·보안 메커니즘 우회로 이어질 수 있어요.

공격 시나리오

시나리오 #1

소셜 네트워크가 사용자가 프로필 사진을 올릴 때, 파일을 직접 업로드하거나 이미지 URL을 제공하는 방식 중 하나를 선택하게 한다고 해볼게요. URL 방식은 아래와 같은 API 호출을 유발해요.

POST /api/profile/upload_picture

{
  "picture_url": "http://example.com/profile_pic.jpg"
}

이때 공격자가 악성 URL을 보내면, 이 API 엔드포인트를 통해 내부망에 대한 포트 스캔을 수행할 수 있어요.

{
  "picture_url": "localhost:8080"
}

응답 시간을 보고 공격자는 해당 포트가 열려 있는지 판단할 수 있어요.

시나리오 #2

API 백엔드가 생성 과정에서 사용자가 제공한 웹훅 URL로 테스트 요청을 보내고, 그 응답을 사용자에게 보여준다고 해볼게요. 공격자는 이 흐름을 악용해, 클라우드 내부 메타데이터 서비스처럼 자격 증명을 노출하는 민감한 자원으로 API가 요청을 보내게 만들 수 있어요.

예방 방법

  • 자원을 가져오는 메커니즘을 네트워크에서 격리해요. 이런 기능은 본래 내부 자원이 아니라 원격 자원을 가져오기 위한 것이므로, 내부 네트워크에 접근하지 못하게 분리하는 게 기본이에요.
  • 가능하면 허용 목록(allow list)을 사용해요. 사용자가 내려받을 것으로 예상되는 원격 출처(예: Google Drive, Gravatar)와 URL 스킴·포트를 제한해요.
  • 웹훅, URL 이미지, URL 미리보기처럼 사용자 입력이 외부 자원 접근으로 이어지는 기능을 만들 때는 도메인/포트/스킴 검증을 항상 넣어요.

더 알아보기