Coders Conquer Security OWASP Top 10 API 시리즈 - 리소스 부족 및 속도 제한

리소스 부족 및 속도 제한 미비로 인한 API 취약점은 이름 그대로의 의미를 담고 있습니다. 모든 API는 환경에 따라 제한된 리소스와 컴퓨팅 파워를 가집니다. 또한 대부분의 API는 사용자나 다른 프로그램으로부터 기능을 수행하라는 요청을 처리해야 합니다. 이 취약점은 너무 많은 요청이 동시에 들어오는데 API가 이를 처리할 충분한 컴퓨팅 리소스를 갖추지 못했을 때 발생합니다. 결과적으로 API는 사용할 수 없게 되거나 새로운 요청에 응답하지 못하게 됩니다.

API의 속도 제한이나 리소스 제한이 올바르게 설정되지 않았거나 코드에서 정의되지 않은 경우 이러한 문제에 취약해집니다. 예를 들어 비즈니스 트래픽이 급증하는 시기에 API에 과부하가 걸릴 수 있습니다. 하지만 이는 보안 취약점이기도 합니다. 공격자가 서비스 거부(DDoS) 공격을 수행하기 위해 보호되지 않은 API에 의도적으로 과도한 요청을 보낼 수 있기 때문입니다.

그나저나 지금까지 진행한 API 게임화 챌린지는 어떠셨나요? 지금 바로 속도 제한 취약점을 다루는 실력을 테스트해보고 싶다면 아레나에 입장해 보세요:

이제 조금 더 자세히 알아보겠습니다.

리소스 부족 및 속도 제한 API 취약점의 사례에는 어떤 것들이 있을까요?

이 취약점이 API에 침투하는 경로는 크게 두 가지입니다. 첫 번째는 개발자가 API의 스로틀링(throttle) 속도를 정의하지 않는 경우입니다. 인프라 어딘가에 기본 스로틀링 설정이 있을 수 있지만, 그것에만 의존하는 것은 좋은 정책이 아닙니다. 대신 각 API마다 개별적으로 속도를 설정해야 합니다. API마다 기능과 가용 리소스가 크게 다를 수 있기 때문입니다.

예를 들어, 소수의 사용자만을 위한 내부 API는 매우 낮은 스로틀링 속도로도 충분히 작동할 수 있습니다. 하지만 라이브 이커머스 사이트의 일부인 공개 API는 동시 접속자 급증에 대비해 매우 높은 속도 제한이 필요할 것입니다. 두 경우 모두 예상되는 요구 사항, 잠재적 사용자 수, 가용 컴퓨 팅 파워를 기반으로 스로틀링 속도를 정의해야 합니다.

특히 매우 바쁜 API의 경우 성능을 극대화하기 위해 속도 제한을 무제한으로 설정하고 싶은 유혹이 생길 수 있습니다. 이는 간단한 코드 조각으로 구현할 수 있습니다(예시로 Python Django REST framework를 사용하겠습니다):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

이 예시에서 익명 사용자와 시스템에 등록된 사용자 모두 시간당 요청 횟수에 제한 없이 API에 무제한으로 접근할 수 있습니다. 이는 매우 위험한 생각입니다. API가 아무리 많은 컴퓨팅 리소스를 가지고 있더라도, 공격자는 봇넷 등을 동원해 API를 느려지게 하거나 완전히 오프라인 상태로 만들 수 있기 때문입니다. 이런 상황이 발생하면 정상적인 사용자는 접근이 차단되며 공격은 성공하게 됩니다.

리소스 부족 및 속도 제한 문제 해결하기

조직에서 배포하는 모든 API는 코드 내에 스로틀링 속도가 정의되어 있어야 합니다. 여기에는 실행 시간 초과(timeout), 최대 허용 메모리, 사용자에게 반환되는 페이지당 레코드 수, 또는 정의된 시간 내에 허용되는 프로세스 수 등이 포함될 수 있습니다.

위의 예시에서 스로틀링 속도를 무제한으로 두는 대신, 익명 사용자와 등록된 사용자에 대해 각각 다른 속도를 엄격하게 정의할 수 있습니다.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

새로운 예시에서는 API가 익명 사용자의 요청을 시간당 200회로 제한합니다. 시스템에 의해 검증된 등록 사용자에게는 시간당 5,000회로 더 많은 여유를 줍니다. 하지만 이들조차도 피크 타임의 우발적인 과부하를 방지하거나, 사용자 계정이 탈취되어 서비스 거부 공격에 악용되는 상황을 대비해 제한을 두어야 합니다.

마지막으로 고려해야 할 좋은 관행은 사용자가 스로틀링 제한에 도달했을 때 알림을 표시하고, 언제 제한이 해제되는지 설명해 주는 것입니다. 이렇게 하면 정상적인 사용자는 왜 애플리케이션이 요청을 거부하는지 이해할 수 있습니다. 또한 승인된 작업을 수행하는 정상적인 사용자가 API 접근을 거부당할 경우, 운영 담당자에게 스로틀링 상향 조정이 필요하다는 신호를 줄 수 있어 유용합니다.

이 취약점에 대한 더 자세한 정보와 조직 및 고객을 다양한 보안 위협으로부터 보호하는 방법은 Secure Code Warrior 블로그에서 확인하실 수 있습니다. 또한 데모를 체험하여 사이버 보안 기술을 지속적으로 연마하고 최신 상태로 유지해 보세요.