사용자가 준 URL을 서버가 대신 읽는 기능을 만듭니다. HTTP 주소인지 검사하는 것만으로 SSRF를 막을 수 있나요?

서버가 요청할 수 있는 내부망·metadata·관리 endpoint를 사용자가 간접 호출하게 되는 것이 SSRF의 핵심입니다. 스킴 검사뿐 아니라 목적지·주소 해석·리다이렉트·응답 크기·네트워크 권한을 제한해야 합니다.

동작 원리와 전제

허용 도메인 목록을 사용할 수 있으면 범위를 좁히고, URL 파서를 사용해 userinfo·포트·IP 표현의 혼동을 막습니다. DNS가 외부 주소로 검증된 뒤 내부 주소로 바뀌는 경우와 redirect 목적지도 검사합니다. 애플리케이션 검사와 실제 연결 대상이 달라지지 않게 합니다.

선택과 실패 처리

실행 환경의 egress 정책으로 내부망 접근을 제한하고 클라우드 자격을 노출하지 않습니다. 응답 크기·시간·리다이렉트 횟수를 제한하며 지원하지 않는 프로토콜을 거절합니다. 외부 서버에 쿠키·Authorization을 자동 전달하지 않습니다.

구체적인 사례와 검증

최초 URL이 허용 도메인이어도 redirect가 내부 관리 주소를 가리킬 수 있습니다. 각 이동의 최종 연결 대상을 검증하고 허용된 스킴·포트·네트워크 범위를 적용합니다. DNS 검증 후 다른 주소로 연결되는 경쟁을 줄이기 위해 실제 연결 주소와 TLS hostname 검증을 일치시키는 구현이 필요합니다. 프록시 환경 변수나 라이브러리의 자동 인증 전달도 숨은 경로가 될 수 있습니다. 응답을 HTML로 다시 제공한다면 SSRF 방어 외에 XSS·MIME·개인정보 노출을 따로 봅니다. 외부 콘텐츠를 읽는 권한과 그것을 사용자에게 공개하는 권한도 같은 것이 아닙니다.

허가된 격리 테스트에서 loopback·사설 주소·redirect·DNS 변화·큰 응답을 확인합니다. 정상 공개 자료 조회가 가능한지도 검사합니다. URL 문자열이 유효하다는 것과 서버가 그 위치를 읽어도 된다는 권한은 별개입니다.