SSRF (1)

Server Side Request Forgery : SSRF

Server Side Request Forgery란?

서버 측 application이 의도하지 않은 곳으로 request를 보내도록 유도할 수 있는 취약점을 의미한다.

 

전형적으로 SSRF는

:) 조직 인프라 속에 있는 내부 전용 서비스에 연결하도록 

:) 임의의 외부 시스템에 연결하도록 

하여 민감한 데이터를 추출하거나 임의 명령을 실행하는 등의 후속 공격이 이루어질 수 있다.

 

 

SSRF attacks against the server itself

내부 서버 자체에 SSRF 공격을 시도하는 경우, 

공격자는 application을 호스팅 하고 있는 서버로 다시 HTTP request가 보내지도록 packet을 조작할 수 있다.

 

사용자가 아이템의 재고를 확인할 수 있는 쇼핑 application이 있다고 가정할 때 

본 기능대로라면 아래와 같은 packet이 날아가 아이템의 재고가 출력된다.

 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

stockApi 내용을 보면 http://stock.weliketoshop.net:8080에 /product/stock/check라는 경로로

productId와 storeId를 parameter로 전달하는 걸 알 수 있다. 

 

SSRF 공격을 시도하고 싶은 공격자 입장에서는

stockApi 내용을 조작해 server로 이 request가 돌아가게(Back) 만들려고 할 것이다. 

 

** stockApi의 내용은 서버가 참고하여 request를 처리하는 값으로 사용된다. 

서버 측에서 request를 처리하기 위해 필요한 시스템들을 거치며 Api 값을 사용하게 되는 데 

이때 서버 측 시스템들 간의 소통이 발생한다는 게 포인트! 

 

SSRF는 서버 측 시스템들이 request를 처리하기 위해 소통하는 과정에서

하나의 시스템이 의도하지 않은 reuqest를 보내도록 만드는 것이다. 

 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

stockApi를 위와 같이 조작하면 이 packet은 localhost, 즉 서버를 가리키게 되고 

서버의 /admin 경로에 있는 페이지를 response로 받게 된다. 

 

물론 admin 권한의 기능은 허가된 사용자만이 수행할 수 있기 때문에 페이지에 접근한다고 하더라도 

흥미로운 정보를 얻는 다거나 어떤 임의의 기능을 수행하지 못하겠지만 

 

문제는!

admin page에 대한 요청이 로컬 시스템에서 오는 경우에는 access control을 우회할 수 있다. 

대게 로컬 시스템에서 오는 요청은 암묵적으로 신뢰하기 때문에

 

로컬 시스템에서 보내진 요청은 access control 검사를 거치지 않거나

재해 복구 목적을 위해 로그인 없이 관리 액세스를 허용받을 수 있다. 

 

따라서 일반 사용자의 요청과 달리 처리되는 로컬 시스템에 대한 신뢰 관계는 SSRF를 가능하게 하는

치명적인 취약점이 될 수 있다.