SSRF

1. SSRF이란?

Server Side Request Forgery의 약자로 서버 측 요청 위조를 의미한다. 공격자가 웹 애플리케이션을 조작하여 서버가 공격자가 원하는 위치로 HTTP 요청을 보내도록 만드는 취약점이다.

 

일반적으로 사용자가 웹사이트를 이용하면 사용자의 브라우저가 서버에 요청을 보낸다.

사용자 브라우저 → 웹 서버

하지만 웹 애플리케이션 중에는 서버가 다른 서버에 직접 요청을 보내는 기능도 존재한다. 외부 이미지 URL을 입력하면 서버가 이미지를 가져오는 기능, URL의 미리보기를 생성하는 기능, 외부 API에서 데이터를 가져오는 기능 등이 대표적이다.

 

예를 들어 쇼핑몰에서 특정 매장의 상품 재고를 확인하기 위해 다음과 같은 요청을 사용한다고 가정한다.

POST /product/stock
stockApi=http://stock.example.com/check?id=10

 

웹 서버는 사용자가 전달한 stockApi 주소를 확인하고 직접 해당 서버에 요청을 보낸다.

사용자 → 웹 서버 → stock.example.com

정상적인 상황에서는 문제가 없다. 하지만 사용자가 stockApi 값을 자유롭게 변경할 수 있고 서버가 요청 대상에 대한 적절한 검증 없이 해당 주소로 요청한다면 SSRF가 발생할 수 있다.

 

2. SSRF는 어떻게 발생하는가

공격자가 다음과 같이 요청 대상을 변경했다고 가정한다.

stockApi=http://127.0.0.1/admin

 

127.0.0.1은 자기 자신을 나타내는 Loopback 주소이다. 여기서 중요한 것은 이 URL에 실제로 접속하는 주체가 공격자의 컴퓨터가 아니라 웹 서버라는 것이다.

 

공격자의 컴퓨터에서 127.0.0.1에 접속하면 공격자 자신의 컴퓨터를 의미한다. 하지만 SSRF가 존재하는 웹 애플리케이션에 해당 URL을 전달하면 웹 서버가 요청을 수행하기 때문에 127.0.0.1은 웹 서버 자신을 의미하게 된다.

공격자 → 취약한 웹 서버 → 127.0.0.1

따라서 외부에서는 접근할 수 없도록 설정된 서버 내부의 관리 기능이 웹 서버 자신에게는 허용되어 있다면 SSRF를 통해 해당 기능에 접근할 가능성이 생긴다.

 

예를 들어 관리자 페이지가 다음 주소에서 실행되고 있다고 가정한다.

http://127.0.0.1/admin

외부 사용자가 자신의 브라우저에서 이 주소를 입력한다고 해서 해당 서버의 관리자 페이지에 접근할 수 있는 것은 아니다. 자신의 127.0.0.1에 접근하기 때문이다.

하지만 취약한 서버에 다음과 같은 URL을 전달할 수 있다면 상황이 달라진다.

http://127.0.0.1/admin

서버가 이 주소로 직접 요청하면서 원래 외부에서는 접근할 수 없었던 내부 기능에 도달할 수 있다.

 

3. 내부 네트워크로 이어지는 SSRF

SSRF가 위험한 이유는 서버가 공격자와 다른 네트워크 위치에 있기 때문이다. 기업의 웹 서버 뒤에는 데이터베이스 서버, 관리 서버, 내부 API와 같이 인터넷에 직접 공개되지 않은 시스템이 존재할 수 있다. 외부 사용자는 이러한 시스템에 직접 접근할 수 없더라도 웹 서버에서는 업무상 필요한 이유로 접근할 수 있는 경우가 있다.

 

이때 공격자는 취약한 웹 서버를 일종의 중간 지점으로 사용하여 자신이 직접 접근할 수 없는 시스템으로 요청을 보낼 수 있다.

예를 들어 웹 서버가 다음과 같은 내부 주소에 접근할 수 있다고 가정한다.

http://192.168.0.10
http://192.168.0.20
http://10.0.0.5

공격자가 SSRF를 통해 요청 대상을 변경하면서 응답의 차이를 확인할 수 있다면 내부 네트워크에서 어떤 시스템이 존재하는지 파악하는 데 악용될 수 있다.

 

4. 클라우드 환경에서의 SSRF

SSRF는 클라우드 환경에서도 중요하게 다뤄진다. 클라우드의 가상 머신에서는 인스턴스 내부에서만 접근하도록 설계된 Metadata Service가 사용될 수 있다.

 

대표적으로 AWS EC2에서는 169.254.169.254라는 Link Local 주소를 Instance Metadata Service에 사용한다. 웹 애플리케이션에 SSRF가 존재하고 해당 서버가 Metadata Service에 접근할 수 있는 환경이라면 공격자가 서버를 통해 Metadata Service로 요청을 보내려고 시도할 수 있다. (공격자 → 취약한 웹 서버 → Metadata Service)

 

과거 클라우드 환경에서는 이러한 SSRF와 Metadata Service의 조합이 중요한 공격 경로로 다뤄졌다. AWS는 이러한 위험을 줄이기 위해 세션 기반 요청 방식을 사용하는 IMDSv2를 제공하고 있으며 환경에 따라 IMDSv1을 비활성화하고 IMDSv2 사용을 강제할 수 있다.

 

5. Blind SSRF

SSRF에서 반드시 응답 내용이 공격자에게 보여야 하는 것은 아니다. 서버가 공격자가 지정한 URL로 요청을 보내고 그 응답까지 사용자에게 반환한다면 공격자는 내부 서비스의 응답 내용을 직접 확인할 수 있다.

 

반면 서버가 요청은 보내지만 결과를 사용자에게 보여주지 않는 경우도 있다. 이를 Blind SSRF라고 한다. 예를 들어 공격자가 자신의 테스트 서버 주소를 입력했는데 웹 애플리케이션 화면에는 아무런 결과가 나타나지 않는다고 가정한다. 하지만 테스트 서버의 로그를 확인했을 때 취약한 서버에서 실제 HTTP 요청이 도착했다면 서버 측 요청이 발생했다는 것을 확인할 수 있다.

 

즉 일반적인 SSRF에서는 요청 결과가 애플리케이션의 응답에 나타날 수 있지만 Blind SSRF에서는 서버가 요청을 보냈다는 사실을 외부 상호작용이나 다른 간접적인 방법을 통해 확인하게 된다.

 

6. SSRF는 어디에서 발생할까

SSRF가 발생하는 기능은 생각보다 다양하다. URL을 입력하여 이미지를 가져오는 기능, 웹페이지 미리보기 기능, 외부 API 연동 기능, Webhook 기능, 파일 Import 기능처럼 사용자가 제공한 주소를 서버가 직접 방문하는 구조라면 SSRF 가능성을 고려할 수 있다.

 

예를 들어 프로필 이미지를 URL로 등록할 수 있는 서비스가 있다고 가정한다.

POST /profile/image
imageUrl= https://example.com/profile.jpg

 

정상적으로는 서버가 example.com에 접속해서 이미지를 가져온다.

사용자가 imageUrl을 내부 주소로 변경했을 때 서버가 그대로 요청을 수행한다면 문제가 될 수 있다.

 

7. SSRF 방어 방법

SSRF를 방어할 때 단순히 localhost라는 문자열만 차단하는 것은 충분하지 않다. 같은 네트워크 위치를 나타내는 방법이 여러 가지 존재할 수 있고 URL Parsing이나 Redirect와 같은 요소가 결합될 수도 있기 때문이다. 특정 문자열이 포함되어 있는지만 확인하는 단순한 Blacklist 방식은 우회 가능성을 고려해야 한다. 가능하다면 서버가 요청할 수 있는 대상 자체를 제한하는 Allowlist 방식을 사용하는 것이 안전하다. 애플리케이션이 반드시 특정 API 서버에만 요청해야 한다면 사용자가 임의의 전체 URL을 전달하도록 만드는 것보다 허용된 Host와 Protocol을 명확하게 제한하는 방식이 좋다.

 

URL을 검증할 때는 Protocol과 Host Port 등을 적절한 URL Parser를 통해 확인해야 하며 DNS 해석 이후 실제 연결되는 IP 주소가 내부 네트워크나 Loopback Link Local 주소 등에 해당하는지도 고려해야 한다.

 

Redirect 역시 주의해야 한다. 최초 URL만 정상적인 외부 주소인지 확인한 뒤 Redirect된 최종 목적지를 검증하지 않는다면 처음에는 허용된 주소로 요청한 뒤 다른 위치로 이동하는 상황이 발생할 수 있다.

 

애플리케이션이 서버 측에서 임의의 외부 URL에 요청을 보낼 필요가 없다면 해당 기능 자체를 제한하는 것도 중요한 방어 방법이다. 네트워크 계층에서도 웹 서버가 업무상 필요하지 않은 내부 서비스에 접근하지 못하도록 Outbound Traffic을 제한하면 SSRF가 발생했을 때의 영향을 줄일 수 있다.

 

클라우드 환경에서는 애플리케이션의 SSRF 방어뿐만 아니라 Metadata Service와 IAM 권한도 함께 고려해야 한다. Metadata Service의 보안 기능을 사용하고 애플리케이션에 필요한 최소한의 권한만 부여하면 SSRF가 다른 공격으로 확대되었을 때의 영향을 줄일 수 있다.

 

8. SSRF의 핵심

SSRF의 핵심은 공격자가 서버에 직접 침입해서 내부 네트워크에 접속하는 것이 아니다. 원래 다른 서버에 요청을 보낼 수 있는 정상적인 웹 서버의 기능을 공격자가 자신이 원하는 대상으로 요청하도록 조작하는 것이다.

 

따라서 SSRF를 이해할 때는 공격자가 어디에 접속하는가보다 실제 HTTP 요청을 보내는 주체가 누구인가를 생각하는 것이 중요하다. 일반적인 요청은 사용자의 브라우저가 목적지에 직접 요청하지만 SSRF에서는 취약한 서버가 공격자를 대신하여 목적지에 요청한다.

 

공격자 → 취약한 서버 → 공격자가 지정한 목적지

 

이 구조 때문에 공격자는 자신의 네트워크 위치에서는 접근할 수 없는 내부 서비스나 서버 자신에게 요청을 보내도록 유도할 수 있으며 이것이 SSRF가 위험한 핵심 이유이다.