1. SSRF(Server-Side Request Forgery)의 위험성
SSRF는 공격자가 서버를 속여, 서버가 접근할 수 있는 내부 자원이나 외부 시스템에 악의적인 요청을 보내게 만드는 취약점입니다. 공격자는 서버가 가진 권한을 이용해 외부에서는 접근이 불가능한 내부 관리자 페이지, DB 서버, 또는 클라우드 메타데이터 서비스(예: AWS의 169.254.169.254)에 접근하여 민감한 정보를 탈취하거나 내부 시스템을 장악할 수 있습니다. 서버 자체가 공격자의 '프록시(Proxy)'가 되는 셈입니다.
2. 흔히 발생하는 취약한 패턴
주로 이미지 업로드(URL 입력 방식), 웹 후크(Webhook), 외부 RSS 피드 읽기 기능 등에서 발생합니다. 사용자가 입력한 URL을 서버가 검증 없이 HttpURLConnection이나 RestTemplate 등으로 호출할 때 보안 구멍이 생깁니다. 공격자는 http://localhost:8080/admin이나 http://192.168.0.1/과 같은 주소를 주입하여 내부 서비스의 반응을 살피고 공격 지점을 찾아냅니다.
3. 실무적 대응: 화이트리스트 기반의 목적지 통제
단순한 입력값 필터링만으로는 SSRF를 완벽히 막기 어렵습니다. 다음과 같은 다중 방어막이 필요합니다.
• 화이트리스트(Allowlist) 적용: 서버가 통신해야 할 외부 도메인이나 IP 리스트를 미리 정의하고, 그 외의 요청은 모두 차단합니다.
• 내부 IP 대역 차단: 입력받은 주소가 루프백(127.0.0.1), 사설망(10.0.0.0/8, 192.168.0.0/16 등), 클라우드 메타데이터 주소인지 확인하여 차단합니다.
• URL 스키마 제한: http나 https 외에 file://, gopher://, dict:// 등 위험한 프로토콜 사용을 금지합니다.
• 입력값 정규화 및 DNS 검증: 호스트 이름을 IP로 변환한 후, 그 IP가 안전한 대역인지 다시 한번 검사합니다(DNS Rebinding 공격 방지).
4. CWE-918 대응 및 안전한 URL 호출 자바 코드 예시
코멘트: SSRF 방어의 핵심은 "서버의 발을 묶는 것"입니다. 서버가 외부의 요청에 따라 아무 곳이나 돌아다니지 못하도록 허용된 구역(화이트리스트)을 명확히 설정하십시오. logger.debug()를 통해 비정상적인 내부망 접근 시도를 기록하되, 우리 서버가 내부 자원을 탈취하는 공격자의 앞잡이가 되지 않도록 철저한 검증 루틴을 구축하는 것이 시큐어 코딩의 핵심입니다.
댓글 달기