API9:2023 Improper Inventory Management
위협 요소/공격 경로 | 보안 취약점 | 영향 |
API 명세: 악용 용이함 | 확산성: 탐지 가능성->Average | 기술적 심각도: 특정 비지니스 |
위협 요소는 일반적으로 이전 API 버전이나 패치가 적용되지 않고 보안 요구 사항이 적용 되어있지 않은 end-points를 통해 무단 액세스를 하게됩니다. 어떤 경우에는 익스플로잇이 가능합니다. 또는 데이터를 공유할 이유가 없는 제3자를 통해 민감한 데이터에 액세스할 수도 있습니다. | 오래된 문서는 취약점을 찾거나 고치는 것을 더욱 어렵게 만듭니다. 자산재고 및 폐기 전략이 부족하면 패치가 적용되지 않은 시스템이 실행되어 민감한 데이터가 유출될 수 있습니다. 애플리케이션을 쉽게 배포하고 독립적으로 만들 수 있는 마이크로서비스(예: 클라우드 컴퓨팅, K8S)와 같은 최신 개념으로 인해 불필요하게 노출된 API 호스트를 찾는 것이 일반적입니다. 간단한 Google Dorking, DNS enumeration또는 전문 검색엔진을 사용하면 대상을 발견하기 충분합니다. | 공격자는 중요한 데이터에 대한 액세스하거나, 서버를 장악할 수 있습니다. 종종 다른 API버전 배포가 실제 데이터로 동일한 데이터베이스에 연결됩니다. 위협 요소는 관리 기능에 액세스하거나 알려진 취약성을 이용하기 위해 오래된 API 버전에서 사용할 수 있는 사용되지 않은 end-points를 이용할 수 있습니다. |
취약한 API
광범위하게 연결된 API와 최신 애플리케이션의 특성은 새로운 과제를 가져옵니다. 조직에서는 자체 API와 API end-points 뿐만 아니라 API가 외부 third-party와 데이터를 저장하거나 공유하는 방법을 잘 이해하고 가시성 있게 유지하는 것이 중요합니다.
여러 버전의 API를 실행하려면 공격방식에 대한 API공급자의 추가 관리 리소스가 필요합니다.
API의 문서화의 사각지대:
API 호스트의 목적이 불분명하며 다음 질문에 대한 명시적인 답변이 없습니다
민감한 데이터 흐름의 가시성과 인벤토리는 third-party에서 침해가 발생할 경우 사고 대응 계획의 일부로써 중요한 역할을 합니다.
API의 데이터흐름 사각지대:
•
API가 third-party와 민감한 데이터를 공유하는 "sensitive data flow"가 있고
•
흐름에 대한 사업적 정당성이나 승인이 없습니다
•
흐름에 대한 인벤토리 또는 가시성이 없습니다
•
어떤 유형의 중요한 데이터가 공유되는지에 대한 가시성이 깊지 않습니다
공격 시나리오
Scenario #1
소셜 네트워크는 공격자가 무차별 대입 공격을 통해 재설정된 비밀번호 토큰을 추측하는 것을 차단하는 속도 제한 메커니즘을 구현했습니다. 이 메커니즘은 API 코드 자체의 일부가 아니라 클라이언트와 공식 API(api.socialnetwork.owasp.org ) 사이의 별도 구성 요소로 구현되었습니다. 한 연구자가 재설정된 암호 메커니즘을 포함하여 동일한 API를 실행하는 베타 API호스트(beta.api.socialnetwork.owasp.org)를 발견했지만 속도 제한 메커니즘은 실행되지 않았습니다. 연구원은 6자리 토큰을 추측하기 위해 간단한 무차별 대입을 사용하여 모든 사용자의 비밀번호를 재설정할 수 있었습니다.
Scenario #2
소셜 네트워크를 통해 개발자들은 앱과 소셜 네트워크를 통합할 수 있습니다. 이 프로세스의 일부로 최종 사용자의 동의가 요청되므로 소셜 네트워크는 사용자의 개인 정보를 다른 앱과 공유할 수 있습니다.
소셜 네트워크와 다른 앱 사이의 데이터 흐름은 제한적이지 않거나 모니터링이 충분하지 않기 때문에 앱이 사용자정보 뿐만 아니라 모든 친구의 개인 정보에도 접근할 수 있습니다.
한 컨설팅 회사가 악성 앱을 만들어 270,000명의 사용자의 동의를 얻습니다. 이 결함 때문에 컨설팅 회사는 50,000,000 사용자의 개인 정보에 액세스할 수 있습니다. 나중에 컨설팅 회사는 악의적인 목적으로 정보를 판매합니다.
예방 방법
•
모든 API호스트들을 목록화 하고, 호스트(예: 퍼블릭, 내부, 파트너) 및 API 버전에 대한 네트워크 액세스 권한이 있어야 하는 API 환경(예: 프로덕션, 스테이징, 테스트, 개발)을 중심으로 각 API 호스트의 중요한 측면을 문서화합니다
•
통합 서비스들을 목록화 하여 시스템에서의 역할, 교환되는 데이터(데이터 흐름) 및 민감도와 같은 중요한 부분을 문서화합니다.
•
인증, 오류, 리디렉션, 속도 제한, CORS(Cross-Origin Resource Sharing) 정책 및 end-points와 같은 API의 모든 측면을 문서화합니다(예: 매개 변수, 요청 및 응답).
•
표준정책을 채택하여 자동으로 문서를 생성합니다. CI/CD파이프라인에 문서 빌드를 포함합니다.
•
API 문서를 API 사용 권한이 있는 사람만 사용할 수 있도록 합니다.
•
현재제품 뿐만 아니라 노출된 모든 버전의 API에 대해 전용 보안 솔루션을 도입할 수 있도록 합니다.
•
non-production API 배포 시 제품의 데이터를 사용하지 마십시오. 부득이한 경우 이러한 end-points는 프로덕션 데이터와 동일한 보안 처리를 받아야 합니다.
•
새로운 버전의 API에 보안 개선 사항이 포함되어 있을 경우 위험 분석을 수행하여 이전 버전에 필요한 완화 조치를 알려줍니다. 예를 들어 API 호환성을 깨지 않고 개선 사항을 backport할 수 있는지 또는 이전 버전을 빠르게 제거하고 모든 클라이언트를 최신 버전으로 강제 이동해야 하는지 여부 등입니다.