API testing

1. 정의

웹사이트에서 /api를 통해 회원가입, 정보 수정, 조회 및 삭제 등의 여러 주요 기능을 수행하는 경우가 있다. 이때 해당 웹사이트에 API testing 취약점이 존재한다면, 본래 정상적인 웹사이트 접속을 통해서는 인증 및 인가받지 않은 자가 특정 기능을 이용하려고 할 때 이를 제재할 수 있으나 해당 기능이 실질적으로 적용되는 /api에서 HTTP 매소드를 수정하여 무단으로 해당 기능을 이용해 중요 정보를 탈취, 조작 등을 할 수 있게된다.

따라서 /api에 반드시 사용해야하는 HTTP 매소드를 제외하고는 허용하지 않아야 하며, 인증 및 인가가 필요한 기능의 경우, /api로 접근하더라도 이를 확인하는 로직을 추가해야 한다.

 

2. 실습

해당 취약점에 대한 실습은 burp suite academy의 [API testing]파트 첫번째 LAB 문제인 'Lab: Exploiting an API endpoint using documentation'의 실습 과정이다.

해당 실습을 통해 wiener로 로그인한 상태에서 다른 사용자 계정인 carlos의 계정 정보를 확인하고 이를 삭제하는 실습을 진행하였다.

wiener로 로그인한 뒤, 해당 계정의 이메일 주소를 변경한다.

 

해당 패킷을 Burp Suite에서 확인한 결과 아래와 같이 /api/user/wiener에서 PATCH를 통해 이메일 주소가 변경된 것을 확인할 수 있다.

 

해당 패킷을 Repeater로 보내어 HTTP 요청 명령어를 PATCH에서 GET으로 변경해보았다.

이런식으로 HTTP 요청만 변경하여 정보를 확인할 수 있는 것을 알 수 있었다. 또한, URI를 보면 알 수 있듯이 각 /api/user/[사용자 이름]으로 각 계정별 api 주소가 존재하는 것을 유추할 수 있으며, 본 실습의 목적인 carlos의 계정 정보를 확인하고 이를 삭제하기 위해 /api/user/carlos에 접속한다.

이렇게 wiener로 로그인한 상태에서 타사용자 계정인 carlos에 대한 개인 정보를 조회할 수 있었다. 해당 페이지에서 허용하는 HTTP 요청 명령어가 무엇인지 확인하기 위해 OPTIONS으로 요청 명령어를 변경하여 패킷을 재전송해보았다.

그 결과 위와 같이 해당 페이지에서는 GET, DELETE, PATCH 명령어가 사용 가능한것을 확인할 수 있었다.

마지막으로 carlos 계정을 삭제하기 위해 해당 페이지에 DELETE 패킷을 전송해보았다.

이렇게 타사용자 carlos의 계정 삭제가 정상적으로 이루어진 것을 확인할 수 있다.

 

3. 정리 및 대응방안

위 실습은 취약점에 대해 익히기 위해 쉽게 만들어진 문제이기 때문에 해당 실습만으로는 본 취약점이 비교적 현실성이 떨어져보일 수 있다. 하지만 해당 취약점은 기술적 문제로 인해 발생하는 취약점이 아닌 개발자의 검증 로직 부재로 인해 발생하는 취약점으로 실제 서비스되는 웹사이트에서도 심심치않게 발생하는 취약점이기도 하다.

특히 해당 취약점을 이용하는 것이 기술적으로 어렵지 않고, 프록시 도구만 있으면 누구나 HTTP 매소드를 조작하여 악용할 수 있는 취약점이므로 보안 담당자 및 서비스 개발자는 이를 잘 살펴보고 배포 전 데모 서비스에서 이러한 취약점이 있는지 확인하는 과정을 거쳐야한다.

 

만일 해당 취약점이 발견되는 경우 해당 기능에 필요한 HTTP 매소드를 제외한 나머지는 허용하지 않도록 해야하고, 특히 /api를 통해서 인증 및 인가가 필요한 기능을 이용할 때 해당 접근이 정상적인 접근인지 혹은 해당 페이지에 접근하는 사용자가 인증/인가받은 사용자가 맞는지 등의 검증 로직을 추가해야 한다.