REST API 환경 웹 서버에서의 기존 취약점 탐구

RESTful API의 가장 큰 특징 uniform interface

RESTful API, RESTful API 말만 많이 들어보고 두루뭉실하게만 이해했지 사실 정확히 아는사람은 많이 없을거다.

그래서 찾아보고 공부해본 바, 필자가 이해한 RESTful API는 가장 큰 특징으로 uniform interface를 가진다는것이다.

 

그럼 이 uniform interface는 뭘 말하는걸까?

 

Uniform interface

RESTful API 환경을 구성한다 함은, 이 uniform interface를 필수구성요소로 넣어야함을 뜻한다.
흔히들 Uniform interface만 구성했다고해서 RESTful API 환경을 만들었다고도 한다.(엄밀히 따지자면 uniform interface만 구축했다고 해서 RESTful API를 구축했다 보긴 힘들다.) 그정도로 RESTful API에서 Uniform interface가 차지하는 비중은 크다.
그럼 이 Uniform interface가 어떤 특징을 가진 인터페이스인지 알아보겠다.

1. 리소스가 URI로 식별되야 한다.
   서버의 개별 자원에 대한 고유한 식별자로 URI를 사용해야 한다.
   ex: /user/1(DB의 user자원에 대해 특정할 수 있음)
   
   
2. 리소스를 생성,수정,추가하고자 할 때 HTTP메시지에 표현을 해야 한다.
   자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
   
   
3. 메시지는 스스로 설명할 수 있어야 한다. (Self-descriptive message)
4. 애플리케이션의 상태는 Hyperlink를 이용해 전이되야 한다.(HATEOAS)

이 중 우리가 눈여겨 봐야하는건 1번과 2번이다.

1번과 2번이 무슨 기존 취약점과 어떤 연관이 있는지 한번 살펴보자.

1. 리소스가 URI로 식별되야 한다.

게시글에 대한 파라미터를 위와 같은 방식으로 처리하는 것을 흔히들 봤을 것이다.
이처럼 해당 항목은 파라미터를 URI로써 전달받아 처리해야함을 뜻한다.

 

그래서 이 Uniform interface로 구성된 웹 사이트에서는 위치공개/불필요한 페이지 취약점이 발생하기 굉장히 힘들다. 애초에 확장자를 표현하지도 않아서 파일 다운로드 취약점이 존재하지 않는 한, .bak, .backup, .org, .old, .zip, .log, .sql, .new, .txt, .tmp, .temp과 같은 불필요한 파일에 접근하기 어렵다.

nextjs 프레임워크를 예시로 들자면, URI 라우팅 기능을 통해 위와 같은 사이트를 구현하는 것이라 해당 페이지 하위페이지에는 불필요한 페이지가 발생할 수 없다.

nextjs에서 URI를 통해 리소스를 식별하는 과정은 아래와 같다.

1. test/[라우팅테스트] 폴더의 하위에 index.html 역할을 하는 page.js를 생성
2. 생성한 page.js는 라우트 데이터를 처리하기 위해 인자 props를 함수 인자로써 수신하고, 해당 인자 객체로부터 params 속성을 들고와 라우팅 데이터 처리
3. 그리고 유저가 ‘/test/입력값’으로 접근하게 되면 폴더명으로 만들었던 [라우팅테스트]의 ‘라우팅테스트’가 오브젝트 속성이 되어 ‘라우팅테스트’의 값으로 클라이언트가 입력한 ‘입력값’이 할당됨

이 같은 구조로 이루어져 있어 단순 php로 구성된 웹사이트에 비해 위치공개/불필요한 파일 접근이 압도적으로 어렵다.

 

2. 리소스를 생성/수정/추가하고자 할 때 HTTP 메시지에 표현을 해야한다.

RESTful API 환경에서는 메소드를 통해 메시지를 주고받는 것을 권장한다.
반드시 따라야 할 필요는 없지만 권장되기 때문에 현업자들 사이에서 권장하는 바에 따라 웹이 구현된다.
각 메소드의 권장되는 기준은 아래와 같다.

메소드	권장되는 사용처
GET	단순히 서버에서 유저에게 정보를 뿌려줄 때
POST	유저가 서버에 정보를 저장할 때
PUT	유저가 서버의 정보를 수정할 때
DELETE	유저가 서버의 정보를 삭제할 때

이 때문에 기존 ‘불필요한 메소드’ 취약 항목은 Uniform interface 환경을 겨낭한 항목이라고 보면 되겠다.

 

해당 취약 항목이 나온 배경을 살펴보자면 이렇다.

1. PUT, DELETE 메소드는 각각 수정/삭제할 때의 메소드로 사용하자고 하니 개발자들이 아키텍처 고안자가 권장한대로 개발

2. 해당 기능에서 파라미터 조작 또는 다른 특정 행위를 통해 비인가행위가 발생

3. PUT/DELETE 메소드에서 특정 동작이 발생할 가능성이 높으므로 주의를 위해  'KISA의 주요정보통신기반시설 가이드 라인'에기재

 

근데 여기서 문제가 생긴다.

진단자들은 PUT/DELETE 메소드를 사용하는 페이지에서 문제가 생긴것도 아닌데 단순히 PUT/DELETE 메소드를 사용한다고해서 취약점이라고, KISA 기준에 있다며 취약점으로 잡기 시작해버린것.

OPTIONS 메소드를 넣었더니 PUT이랑 DELETE가 나오더라 > 아묻따 취약과 같은 매커니즘으로 진단한다면, PUT/DELETE 메소드는 RESTful API 특성이라 현업자들이 탐탁찮아 할 것이고, 결국 현업자들이 따지고 들 경우에,

진단자가 불리해질 수 밖에 없다.

 

그래서 해당 취약점은 좀 더 면밀히 파악할 필요가 있다. DELETE, PUT 메소드를 사용하는 기능에서 파라미터 조작을 해본 후, 인가되지 않은 행위가 발생하면 그제서야 해당 취약점이 취약하다 볼 수 있겠다.
그 외의 경우에서는 단순히 PUT과 DELETE가 허용됐다고해서 취약점이라 보긴 힘들다. 원래 그렇게 설계됐는데 어떻게 취약점이라 할 수 있겠는가.

 

그러니 PUT DELETE가 보인다고해서 취약점으로 잡지말고 해당 페이지에서 어떤 부적절한 행위가 가능한지 파악한 후에 취약점으로 잡는게 맞겠다.

 

번외

RESTful API 환경에서 SQL Injection 같이 사용자가 입력한 내용이 서버내에서 구문으로써 동작할 수 있을까?

유저가 서버에 전달한 값을 서버에서 console.log로 찍게한 결과 유저가 전달한 값과 동일한 값이 출력

 

가능하다. 어쨋든 사용자가 전달한 값이 그대로 서버에 전달된다.
이때 개발자가 어떻게 기능을 구현하느냐에 따라 취약점이 발생할 수 있다.

---

https://medium.com/@soqlehsoqleh/rest-api-a26c6af6e8c9

https://m.boostcourse.org/web316/lecture/16740

https://velog.io/@jhyeom1545/REST-API-Uniform-Interface

https://www.igloo.co.kr/security-information/%EB%B6%88%ED%95%84%EC%9A%94%ED%95%9C-%EC%9B%B9-method-%EC%A7%84%EB%8B%A8-%EC%8B%9C-%EB%B0%9C%EC%83%9D%ED%95%98%EB%8A%94-%EB%AC%B8%EC%A0%9C%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91%EB%B0%A9%EC%95%88/

https://meetup.nhncloud.com/posts/92