SSRF: 서버의 외부 요청 통제

01개념과 구성 요소

• 성립 원리사용자의 입력이 서버의 새 네트워크 요청 목적지에 영향을 주는 문제다.
• 권한 이동첫 요청은 브라우저가 보내지만 두 번째 요청은 서버의 네트워크·자격 문맥에서 발생한다.
• 통제 요소목적지 선택·URL 파싱·DNS·리다이렉트·송신 경로·응답 크기를 함께 제한한다.

02서버의 외부 페이지 가져오기 순서

1. 기능 범위 결정정해진 연동 대상은 서비스 ID를 고정 목적지 표에 매핑한다. 임의 URL이 필요한 기능은 별도 송신 정책을 둔다.
2. URL 해석표준 파서가 해석한 scheme·host·port를 검사한다. 문자열에 허용 도메인이 들어 있다는 조건으로 대신하지 않는다.
3. 실제 주소와 연결 통제DNS 응답과 최종 접속 주소가 정책 범위인지 확인하고 IPv4·IPv6·내부·특수 주소 범주를 송신 경로에서 제한한다.
4. Redirect 재평가자동 이동을 끄거나 매 단계에 같은 검사를 적용한다. 다른 origin에 인증 헤더·쿠키를 전달하지 않는다.
5. 응답 제한시간·크기·이동 횟수의 한도를 적용하고 필요한 응답 필드만 사용자에게 돌려준다.

03브라우저의 요청이 서버의 새 요청으로 바뀌는 지점

• 서버 요청SSRF는 사용자가 제공한 주소를 서버가 대신 가져오는 기능에서 생긴다. 예를 들어 링크 미리보기 서비스는 URL을 입력받아 서버의 HTTP 클라이언트로 페이지를 가져온다.
• 네트워크 권한사용자는 서버 네트워크에 직접 들어가지 않아도 서버가 볼 수 있는 대상으로 요청을 보내게 할 수 있다. 이때 첫 요청의 발신자는 브라우저지만 두 번째 요청의 발신자는 서버다.
• 관련 기능웹훅 테스트, 원격 이미지 가져오기, 문서 변환, 외부 API 프록시도 같은 데이터 흐름을 가진다. OWASP Top 10 2021은 SSRF를 A10으로 분류한다.
• 클라이언트 동작주소가 문자열이라는 이유로 단순 입력 검증만 적용하면 서버의 네트워크 권한과 HTTP 클라이언트의 동작이 빠진다.

04취약한 데이터 흐름과 제한된 정상 기능

• URL 통제 범위가상의 미리보기 기능에서 fetch(user_url)를 그대로 수행하면 입력에 의해 scheme·host·port·path가 모두 결정된다. 외부 이미지만 필요한 기능이라면 모든 종류의 URL을 지원할 이유가 없다.
• 허용 목적지주소를 표준 파서로 해석한 뒤 허용된 스킴·대상·포트라는 기능 조건을 먼저 적용한다.
• ID 매핑·전용 Fetcher대상이 정해져 있는 연동 기능은 외부 URL 대신 서비스 ID를 받고 서버의 고정 목적지 표에서 주소를 선택할 수 있다. 다양한 인터넷 페이지를 가져와야 한다면 단순 호스트 허용 목록으로 요구를 만족시키기 어려우므로 전용 fetcher와 송신 제어가 함께 필요하다.

입력: {"provider": "training-feed", "item": "42"}
서버 설정: training-feed → https://feed.example.test/items/
요청 목적지: 서버 설정에서 선택한 origin
응답: 필요한 제목·요약 필드만 추출

대조할 구조: 사용자 전체 URL → 제한 없는 서버 HTTP 클라이언트

원리를 설명하는 가상 학습 예시입니다.

05URL 파싱과 DNS 확인은 서로 다른 단계

• 파서 간 해석문자열에 허용 도메인이 포함되는지만 검사하면 사용자 정보 부분, 하위 도메인, 경로에 들어간 동일 문자열을 호스트로 오인할 수 있다. 파서가 해석한 host를 기준으로 정책을 적용해야 하며, 검증 코드와 실제 HTTP 클라이언트가 서로 다른 URL 규칙을 사용하면 둘의 해석 차이도 위험이 된다.
• DNS와 연결 시점호스트 이름 검증 뒤에는 DNS가 결정하는 실제 주소가 남는다. 허용된 이름이 나중에 다른 주소로 바뀌거나 검증 시점과 연결 시점의 응답이 달라지면 이름만 승인한 정책으로는 최종 목적지를 보장할 수 없다.
• 송신 정책IPv4와 IPv6, 여러 DNS 응답, 로컬·내부·특수 주소 범주를 포함한 송신 정책을 연결 경로에서 적용하는 이유다.

06Redirect가 목적지 검사를 다시 요구하는 이유

• 자동 RedirectHTTP 클라이언트가 3xx 응답을 자동으로 따라가면 최초 주소와 최종 연결 주소가 달라질 수 있다. 첫 요청만 허용 도메인인지 검사한 뒤 redirect를 무제한 허용하면 이후 단계의 다른 호스트·포트가 검증을 벗어난다.
• 단계별 재검사리다이렉트를 끄거나 매 단계에서 동일한 목적지 정책을 다시 적용해야 한다.
• 자격 전송인증 헤더·쿠키를 다른 origin으로 전달하지 않는 것도 별도 조건이다. 서버 클라이언트에 기본으로 설정된 자격 증명이 임의 외부 주소에 붙는 구조라면 내부 접근뿐 아니라 비밀의 외부 전송도 일어날 수 있다.
• 응답 제한사용자에게 돌려주는 본문·헤더 역시 목적에 필요한 부분으로 제한해야 한다.

10응답이 보이는 경우와 Blind SSRF

• 반환형·Blind서버가 가져온 응답 본문을 사용자에게 그대로 반환하면 내부 서비스의 내용이 직접 드러날 수 있다. Blind SSRF에서는 본문을 보지 못하더라도 요청 성공 여부, 응답 시간, 작업 상태, 자신이 관리하는 수신 서버의 로그 등으로 서버의 요청이 발생했다는 사실을 관찰할 수 있다.
• 같은 요청 원리이 차이는 반환 데이터의 차이이며 서버가 요청을 수행한다는 근본 구조는 같다.
• 오류 해석 한계HTTP 오류나 시간 차이 하나만으로 특정 내부 서비스를 확정할 수는 없다. DNS·프록시·연결 시간 초과와 원격 서버 처리 지연이 섞일 수 있기 때문이다.
• 모의 수신점학습에서는 소유한 모의 수신 엔드포인트에 무해한 식별자를 보내고 요청 시각과 서버 로그를 연결하면 네트워크 추측에 의존하지 않고 흐름을 설명할 수 있다.

11클라우드·내부 서비스에서 영향이 확대되는 조건

• 내부 자원클라우드 메타데이터와 내부 관리자 서비스는 서버가 접근할 수 있는 자원의 예다. 영향은 서버가 그 주소에 도달할 수 있는지, 대상이 추가 인증을 요구하는지, 얻은 자격 증명에 어떤 권한이 있는지에 달린다.
• 성립 조건SSRF가 있다는 이유만으로 모든 클라우드 자원을 장악했다고 단정할 수 없다.
• 피해 범위 제한서비스 계정 최소 권한과 메타데이터 접근 보호는 SSRF 발생 이후의 피해 범위를 줄인다. 전용 fetcher를 내부 데이터베이스·관리망에 도달할 수 없는 네트워크에 배치하면 애플리케이션 검증이 실패해도 송신 경계가 남는다.
• 네트워크 분리정상 요청에 필요한 제한적 외부 연결과 내부 관리 접근을 같은 서버 권한으로 묶지 않는 구조다.

12방어를 결과 흐름으로 읽기

• 정상·거부 결과허용된 모의 외부 페이지는 정상적으로 가져오고, 허용되지 않은 스킴·포트·redirect 목적지는 요청 전에 거부되는 것이 기본 동작이다. 주소 검증 실패와 네트워크 실패는 내부 로그에서 원인을 구분하되, 사용자에게 내부 주소·스택·자격 증명을 노출하지 않는다.
• 자원 한도타임아웃·응답 크기·redirect 횟수 한도는 SSRF 외에도 fetcher 자원 고갈을 제한한다.
• 직접 접근과 구분브라우저가 관리자 경로를 직접 요청하는 문제는 서버의 새 연결을 이용하는 SSRF와 구분한다. SSRF와 구분하는 핵심 질문은 “권한을 가진 서버가 사용자의 입력에 따라 새 연결을 만들었는가”이다.