SSRF는 단순한 URL 필터 문제가 아니라 클라우드 ID 문제다

요약: 서버 측 요청 위조는 무해해 보이는 가져오기 기능을 내부 서비스와 클라우드 자격 증명에 접근하는 통로로 바꿀 수 있습니다. 지속 가능한 방어를 위해서는 목적지, 리디렉션, DNS 해석, 워크로드 ID를 함께 제한해야 합니다.

취약한 기능은 흔히 무해해 보인다

애플리케이션은 링크 미리보기, 웹훅, 문서 가져오기, 이미지 처리, 보안 스캔을 위해 원격 콘텐츠를 가져옵니다. 공격자가 목적지의 일부라도 통제하고 서버가 공격자에게는 닿지 않는 네트워크에 접근할 수 있을 때 위험이 시작됩니다. 애플리케이션은 서버의 신뢰를 내부 영역으로 전달하는 프록시가 됩니다.

짧은 문자열 차단 목록만으로는 충분하지 않습니다. 대체 IP 표기, IPv6 형식, 리디렉션, 사용자 정보 구문, DNS 리바인딩은 겉으로 공개된 URL을 검증 통과 후 루프백 주소, 사설 서비스 또는 클라우드 메타데이터 엔드포인트를 향하는 요청으로 바꿀 수 있습니다.

모든 네트워크 결정을 검증하라

• 필요한 스킴과 포트만 허용하고 자격 증명, 프래그먼트, 모호한 호스트 구문, 비정규 주소 형식을 거부합니다.
• 호스트 이름을 해석하고 반환된 모든 주소를 분류한 뒤, IPv4와 IPv6 모두에서 루프백, 사설, 링크 로컬, 멀티캐스트, 예약 대역을 거부합니다.
• 모든 리디렉션 목적지를 다시 검증하고 연결을 검증된 주소에 고정해 검사와 요청 사이에 DNS가 바뀌지 못하게 합니다.
• 허용된 가져오기가 리소스 고갈 경로로 변하지 않도록 응답 크기, 콘텐츠 유형, 시간 제한, 리디렉션 횟수를 제한합니다.

네트워크 통제로 애플리케이션 검사를 뒷받침해야 한다

애플리케이션 검증은 계속 바뀌고 회귀할 수 있으므로 런타임에는 독립적인 아웃바운드 경계가 필요합니다. 좁은 허용 목록, 격리된 네트워크 경로, 운영 제어 영역에 대한 접근 권한이 없는 전용 가져오기 서비스를 사용하면 파서 오류가 도달할 수 있는 범위를 크게 줄일 수 있습니다.

클라우드 메타데이터 보호도 중요합니다. 지원되는 환경에서는 세션 기반 메타데이터 프로토콜을 요구하고, 네트워크 계층에서 메타데이터 경로를 차단하며, 가져오기 워크로드에는 가능한 한 최소한의 ID 권한만 부여합니다. 요청이 내부 자격 증명 엔드포인트에 도달하더라도 훔칠 만한 것이 거의 또는 전혀 없어야 합니다.

단일 페이로드가 아니라 우회 유형을 테스트하라

익숙한 메타데이터 주소로 요청 하나를 보내는 것은 스모크 테스트에 불과합니다. 완전한 SSRF 테스트 모음은 인코딩 기법, 10진수·16진수 주소, 혼합 IPv6 표기, 리디렉션 체인, DNS 변경, 파서 간 해석 차이, 내부 호스트 이름을 다룹니다. 실패 시 응답 시간이나 본문 일부가 유출되지 않는지도 검증합니다.

KENSAI의 증거 우선 접근법은 목적지 분류와 실제 연결된 주소를 기록합니다. 이를 통해 겉으로만 차단된 상태가 아니라 요청이 의도한 네트워크 경계를 넘지 않았다는 검증 가능한 증거를 확보합니다.

핵심 요약

원격 가져오기를 권한 있는 네트워크 접근으로 취급하십시오. 목적지를 검증해 고정하고, 리디렉션을 다시 검사하며, 아웃바운드 통신을 제한하고, 워크로드 ID 권한을 최소화해 단 한 번의 파싱 오류가 클라우드 침해로 이어지지 않게 해야 합니다.