Coders Conquer Security OWASP Top 10 API 시리즈 - 보안 기능 비활성화/디버그 기능 활성화/부적절한 권한 설정

이 목록에 있는 대부분의 취약점은 API에 특화되어 있지만, 보안 기능 비활성화, 디버그 기능 활성화, 부적절한 권한 설정 문제는 어디에서나 발생할 수 있습니다. API에서 조금 더 흔하게 나타나긴 하지만, 공격자들은 네트워크 어디에서든 패치되지 않은 결함이나 보호되지 않은 파일 및 디렉토리를 찾으려 합니다. 디버깅이 활성화되어 있거나 보안 기능이 꺼진 API를 발견하는 것은 공격자들의 악의적인 작업을 훨씬 수월하게 만듭니다. 더 나쁜 점은 보안 설정을 탐지하고 악용하는 자동화 도구가 존재한다는 것입니다. 따라서 환경 내에 이러한 설정이 있다면 악용될 가능성이 높으며, 이것이 바로 이 취약점이 OWASP의 위험한 API 결함 목록에 포함된 이유입니다.

본격적으로 시작하기 전에, 이 디버그 문제를 해결할 수 있는지 확인해 보세요:

보안 기능 비활성화, 디버그 기능 활성화, 부적절한 권한 설정 결함은 어떻게 API에 침투할까요?

이 다차원적인 API 결함이 네트워크에 어떻게 추가되는지 이해하려면 구성 요소별로 나누어 살펴봐야 합니다. 먼저 디버그 기능 활성화 문제부터 시작해 보겠습니다. 디버깅은 애플리케이션이 제대로 작동하지 않거나 오류가 발생하는 이유를 개발자가 파악하도록 돕는 유용한 도구입니다. 디버깅이 활성화되면 오류와 예외 발생 시 상세한 오류 페이지가 생성되어 개발자가 문제의 원인을 확인하고 해결할 수 있습니다. 애플리케이션 개발 단계에서는 이를 활성화해 두는 것이 전혀 문제가 되지 않습니다.

하지만 대부분의 프레임워크가 프로덕션 환경에서 디버그 모드를 실행하지 말라고 경고하는 데에는 이유가 있으며, 보통 디버깅이 활성화되는 코드 바로 옆에 해당 경고가 표시됩니다. 예를 들면 다음과 같습니다:

# 보안 경고: 프로덕션 환경에서 디버그 모드를 켠 채 실행하지 마세요!
DEBUG = True

이 예시에서는 디버깅이 활성화되어 있습니다. Django 애플리케이션은 예외가 발생할 때마다 상세한 오류 페이지를 생성합니다. 이를 프로덕션 환경에서 수행하면 공격자가 환경에 대한 메타데이터 정보가 포함된 이 오류 페이지에 접근할 수 있게 됩니다. 대부분의 프레임워크는 기본적으로 디버깅이 꺼져 있지만, 긴 개발 과정 중에 활성화했다가 다시 끄는 것을 잊기 쉽습니다. 애플리케이션이 프로덕션 환경으로 이전되면, 공격자에게 애플리케이션은 물론 서버나 네트워크 전체를 침해할 수 있는 많은 정보를 제공하게 됩니다.

디버그 모드 활성화가 주로 단독적인 문제라면, 부적절한 권한 설정과 보안 기능 비활성화 취약점은 종종 함께 발생합니다. 예를 들어, OWASP가 제시한 실제 사례에서 공격자는 검색 엔진을 사용하여 인터넷에 실수로 연결된 데이터베이스를 찾아냈습니다. 널리 사용되는 이 데이터베이스 관리 시스템은 기본 설정을 사용 중이었기 때문에 인증 기능이 비활성화되어 있었습니다. 결과적으로 공격자는 부적절한 권한 설정과 보안 기능 비활성화 취약점을 결합하여 PII(개인식별정보), 개인 설정, 인증 데이터가 포함된 수백만 개의 기록에 접근했습니다.

보안 기능 비활성화, 디버그 기능 활성화, 부적절한 권한 설정 취약점 제거하기

이 취약점을 제거하려면 이중 접근 방식이 필요합니다. 디버그 기능 활성화 문제를 해결하려면, API나 애플리케이션을 프로덕션 환경으로 옮기기 전에 디버깅이 비활성화되었는지 확인하는 절차를 개발 과정에 추가하기만 하면 됩니다. 앞선 예시에서 이를 위한 올바른 명령은 다음과 같습니다:

# 보안 경고: 프로덕션 환경에서 디버그 모드를 켠 채 실행하지 마세요!
DEBUG = False

이제 DEBUG 플래그가 False로 설정되어 Django 애플리케이션의 디버그 기능이 비활성화되었습니다. 오류가 발생해도 오류 페이지가 생성되지 않습니다. 공격자가 오류 페이지에 접근하더라도 유용한 메타데이터가 포함되어 있지 않으므로 애플리케이션에 위험을 초래하지 않습니다.

보안 기능 비활성화 및 부적절한 권한 설정 취약점을 제거하는 것은 훨씬 더 어렵습니다. 왜냐하면 이들은 광범위하고 구체적인 취약점을 포함할 수 있기 때문입니다. 이를 막는 가장 좋은 방법은 보안이 강화된 자산을 프로덕션 환경에 빠르고 쉽게 배포할 수 있도록 표준화되고 반복 가능한 프로세스를 개발하는 것입니다.

그럼에도 불구하고 오케스트레이션 파일, API 구성 요소, Amazon S3 버킷 권한과 같은 클라우드 서비스 설정을 지속적으로 검토하고 업데이트하는 프로세스를 구축해야 합니다. 또한 이 검토 과정에서 조직 전체의 API 보안이 지속적으로 개선될 수 있도록 환경 전반의 보안 설정 효과를 주기적으로 평가해야 합니다.

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