APISIX가 OWASP 상위 10개 API 보안 위협으로부터 보호하는 방법
October 6, 2023
오늘날 상호 연결된 디지털 환경에서 API의 사용과 의존도가 증가함에 따라, 이를 대상으로 한 보안 위협도 해마다 증가하고 있습니다. 2023년, Open Web Application Security Project (OWASP)는 API 보안에 대한 새로운 Top 10 위협을 발표했습니다. 이 블로그 포스트에서는 각 위협을 탐구하고 APISIX가 이를 방어하는 방법을 예시와 함께 알아보겠습니다.
OWASP는 정기적으로 사이버 보안 관련 연구를 발표하는 전 세계적으로 인정받는 커뮤니티입니다.
OWASP에서 언급한 보안 위험 목록은 다음과 같습니다:
- 객체 수준 권한 부여 취약점
- 인증 취약점
- 객체 속성 수준 권한 부여 취약점
- 무제한 리소스 소비
- 기능 수준 권한 부여 취약점
- 민감한 비즈니스 흐름에 대한 무제한 접근
- 서버 측 요청 위조
- 보안 설정 오류
- 부적절한 인벤토리 관리
- API의 안전하지 않은 소비
1. 객체 수준 권한 부여 취약점
위협: API는 종종 객체 식별자를 처리하는 엔드포인트를 노출시키는데, 이는 객체 수준 접근 제어 문제로 이어질 수 있습니다. 공격자는 이러한 취약점을 악용하여 데이터에 대한 무단 접근을 얻을 수 있습니다.
예시: 한 의료 기관이 온라인 환자 포털을 제공합니다. 포털 설계상의 결함으로 인해, 환자가 인증을 받으면 URL이나 요청 매개변수를 수정하여 다른 환자 ID와 연결된 의료 기록에 접근할 수 있습니다. 예를 들어, 환자 Steve가 환자 포털에 로그인하여 자신의 의료 기록을 확인합니다. 그의 기록은 https://healthportal.com/patient/123 URL을 통해 접근 가능합니다. 호기심에 Steve는 URL을 https://healthportal.com/patient/124로 변경하고 다른 환자의 의료 기록을 볼 수 있음을 발견합니다. 이는 심각한 개인 정보 유출을 초래하며, 건강 보험 이동성 및 책임법(HIPAA)과 같은 규정을 위반합니다.
권장 사항: 사용자 정책과 계층 구조에 기반한 적절한 권한 부여 메커니즘을 구현하세요. APISIX 게이트웨이는 플러그인을 통해 OAuth2 또는 JWT 기반 권한 부여 흐름을 지원합니다. 각 요청에 대해 토큰을 검증하기 위해 OAuth2 정책을 사용할 수 있습니다.
Open Policy Agent (OPA)와 통합하여 APISIX의 역할 기반 접근 제어(RBAC) 시스템을 통해 세분화된 접근 제어를 사용하세요. APISIX에서 특정 역할과 권한을 설정하고 이러한 역할을 특정 사용자나 토큰과 연결함으로써, 민감한 엔드포인트에 대한 요청이 적절히 권한 부여되도록 할 수 있습니다.
2. 인증 취약점
위협: 잘못 구현된 인증 메커니즘은 공격자가 인증 토큰을 손상시키거나, 속도 제한이 없어 공격자가 로그인 엔드포인트를 무차별 대입 공격할 수 있게 합니다.
예시: 은행 시스템이 사용자 정의 인증 메커니즘을 구현했습니다. 그러나 적절한 보안 검토와 테스트가 부족하여 인증 흐름에 취약점이 있었습니다. 구체적으로, 사용자가 사용자 이름과 비밀번호를 입력한 후, 시스템은 사용자 이름과 타임스탬프의 조합과 같은 예측 가능한 세션 토큰을 생성했습니다. 이 결함을 알고 있는 공격자는 다른 사용자의 세션 토큰을 쉽게 예측할 수 있었습니다.
권장 사항: 먼저, API에 대한 모든 가능한 인증 흐름을 이해하고, 인증에서 바퀴를 다시 발명하지 마세요! APISIX는 표준 OpenID Connect (OIDC) 권한 부여 흐름을 지원합니다. 예측 가능한 세션 토큰 대신, APISIX는 Keycloak과 같은 외부 ID 제공자나 플러그인을 사용하여 세션 토큰이 무작위로 생성되고 암호화되며 제한된 수명을 가지도록 할 수 있습니다.
사용자 계정에 대한 무차별 대입 공격을 방지하기 위해 APISIX의 속도 제한 플러그인을 사용할 수 있습니다. 이는 짧은 시간 내에 여러 번의 로그인 시도가 실패하면 IP나 사용자를 일시적으로 차단합니다. 데이터 프라이버시와 무결성을 보장하기 위해 APISIX는 SSL/TLS 암호화를 지원합니다. 이는 사용자 자격 증명과 기타 민감한 데이터가 전송 중에 암호화되도록 합니다.
3. 객체 속성 수준 권한 부여 취약점
위협: 이 위협은 객체 속성 수준에서의 권한 부여 검증이 부족하거나 잘못되어 무단 정보 노출 또는 조작으로 이어질 수 있습니다.
예시: 온라인 쇼핑 플랫폼의 API는 등록된 사용자가 이름, 이메일, 배송 주소, 결제 정보와 같은 프로필 세부 정보를 업데이트할 수 있도록 허용합니다. 또한, 각 사용자 프로필에는 userType이라는 속성이 있으며, 이는 regular 또는 admin일 수 있습니다. API 설계상의 문제로 인해, 사용자는 프로필 업데이트 요청에서 userType 속성도 수정할 수 있습니다. 일반 사용자인 Alice가 브라우저의 개발자 도구를 사용하여 API 요청을 검사할 때 이 결함을 발견합니다. 그녀는 프로필을 업데이트할 때 서버로 전송되는 JSON 페이로드를 확인합니다. Alice는 userType 값을 admin으로 수정하고 요청을 전송합니다. 놀랍게도, 그녀의 프로필이 업데이트되고 이제 플랫폼에서 관리자 권한을 갖게 되어 민감한 데이터에 접근하고, 제품 목록을 수정하고, 다른 사용자의 주문 기록을 볼 수 있게 됩니다.
권장 사항: 노출된 객체 속성이 사용자에게 접근 가능한지 확인하고, 반환된 데이터 구조를 비즈니스 요구 사항에 따라 최소화하세요. 이를 위해 APISIX의 요청 검증 플러그인을 사용하여 미리 정의된 스키마에 대해 들어오는 요청을 검증할 수 있습니다. 또는 APISIX의 RBAC 시스템을 사용하여 일반 사용자와 관리자에 대한 역할을 설정할 수 있습니다. 클라이언트에 노출되는 불필요한 데이터를 제거하기 위해 APISIX는 응답 재작성 플러그인을 제공하여 API 응답을 실시간으로 수정할 수 있습니다.
4. 무제한 리소스 소비
위협: 공격자는 API를 악용하여 과도한 리소스를 소비할 수 있으며, 이는 서비스 거부 공격이나 운영 비용 증가로 이어질 수 있습니다.
예시: 클라우드 기반 파일 저장 서비스는 사용자가 파일을 업로드하고 저장하며, 다른 사람과 공유하고 어디서나 접근할 수 있도록 합니다. 이 서비스는 사용자가 동시에 업로드할 수 있는 파일 수나 각 파일의 크기에 대한 제한이 없습니다. 결과적으로, 악의적인 사용자나 봇이 매우 큰 파일을 빠르게 연속적으로 업로드하여 서버 리소스를 상당히 소모할 수 있습니다. 이는 다른 사용자에게 느린 응답 시간, 잠재적인 서버 충돌, 그리고 서비스 제공자에게 증가된 인프라 비용을 초래할 수 있습니다.
권장 사항:
- 모든 들어오는 매개변수와 페이로드에 대한 최대 데이터 크기를 정의하고 시행하세요. 클라이언트 제어 플러그인을 사용하여 요청 본문의 최대 크기를 설정하여 사용자가 과도하게 큰 파일을 업로드할 수 없도록 할 수 있습니다. 또는 요청 검증 플러그인을 사용하여 반환되는 레코드 수를 제어하는 쿼리 문자열을 검증할 수 있습니다. 원치 않는 데이터를 보내는 봇, 스크립트, 또는 사용자 에이전트를 차단하기 위해 ua-restriction 플러그인을 활용할 수 있습니다.
- 비즈니스 요구에 기반한 속도 제한을 구현하세요. APISIX는 limit-req, limit-conn, limit-count 플러그인을 제공하여 개별 사용자나 IP 주소가 요청을 할 수 있는 속도를 제한할 수 있습니다. 이는 사용자가 시스템에 많은 수의 빠른 요청을 보낼 수 없도록 합니다.
5. 기능 수준 권한 부여 취약점
위협: 접근 제어 정책이 너무 복잡하고 다양한 수준, 그룹, 역할이 있으며, 관리 기능과 표준 기능 간의 구분이 모호하여 종종 권한 취약점이 발생합니다. 공격자는 이러한 약점을 악용하여 다른 사용자의 리소스나 관리 기능에 접근할 수 있습니다.
예시: 온라인 학습 플랫폼은 학생들에게 다양한 코스를 제공합니다. 플랫폼 설계상의 문제로, 학생들이 URL이나 API 엔드포인트를 조작하여 강사 전용 기능에 접근할 수 있습니다. 예를 들어, 학생이 /student/dashboard에서 /instructor/dashboard로 URL을 변경하면 강사의 대시보드에 접근할 수 있어 코스 내용을 수정하거나, 과제를 채점하거나, 심지어 코스를 추가/삭제할 수 있습니다.
권장 사항:
- 기본적으로 모든 접근을 거부하고 특정 역할에 대해 명시적으로 권한을 부여하세요. APISIX를 사용하여 소비자 또는 소비자 그룹을 생성하여 사용자에게 다른 접근 제어를 제공할 수 있습니다. 그런 다음, JWT 인증 플러그인을 구성하여 JWT 토큰에 역할 정보를 포함시킬 수 있습니다. 사용자가 로그인하면 받는 JWT 토큰에는 역할(
student또는instructor)이 포함됩니다. APISIX는 특정 기능에 대한 접근을 허용하기 전에 JWT 토큰에서 사용자의 역할을 확인할 수 있습니다. - 관리 컨트롤러가 사용자 역할에 기반한 권한 검사를 구현하는 컨트롤러에서 상속받도록 하세요. API7 엔터프라이즈를 사용하면 관리자가 특정 사용자/그룹에 대한 API 접근을 제한하고, 요청 및 사용자별로 접근을 설정할 수 있습니다.
6. 민감한 비즈니스 흐름에 대한 무제한 접근
위협: 민감한 비즈니스 흐름이 위험 평가 없이 노출되어, 자동화되고 과도한 방식으로 사용될 경우 비즈니스에 해를 끼칠 수 있습니다.
예시: 프록시와 자동화된 스크립트(봇)를 조합하여 공격자는 여러 실제 사용자가 구매를 하는 것처럼 시뮬레이션합니다. 스크립트는 제품을 빠르게 장바구니에 추가하고 결제 프로세스를 완료하여 실제 고객이 구매할 기회를 갖기 전에 재고를 소진시킵니다. 공격자는 이 제품을 다른 플랫폼에서 더 높은 가격에 재판매합니다. 판매자 플랫폼은 실제 고객에게 의도한 가격으로 제품을 판매할 수 없어 잠재적인 수익을 잃게 됩니다.
권장 사항:
- 예상치 못한 클라이언트 장치에 대한 서비스를 거부하기 위해 장치 지문 인식을 구현하세요. APISIX는 Auth0, Authgear와 같은 ID 및 접근 관리 플랫폼과 통합하여 생체 인식 로그인 기능을 포함한 다양한 인증 메커니즘을 활성화할 수 있습니다.
- 캡차나 고급 생체 인식 솔루션과 같은 인간 탐지 메커니즘을 사용하세요. 위와 동일합니다.
- 비인간적인 패턴을 감지하기 위해 사용자 흐름을 분석하세요. API7 엔터프라이즈를 사용하여 다른 로그인 위치 간의 높은 속도나 봇 탐지와 같은 비인간적인 패턴과 관련된 요청에 대해 추가 인증 요소를 시행할 수 있습니다.
- 알려진 악성 소스의 IP 주소를 차단하세요. APISIX는 ip-restriction 플러그인을 사용하여 단일 또는 여러 IP 주소에서의 접근을 차단할 수 있습니다.
7. 서버 측 요청 위조 (SSRF)
위협: SSRF 공격은 공격자가 서버의 내부 리소스에 요청을 보내 내부 네트워크, 파일 시스템, 또는 심지어 명령을 실행할 수 있게 합니다. 이는 API 엔드포인트가 URL이나 그 일부를 입력으로 받아들이고 적절한 검증 없이 이를 가져올 때 발생합니다.
예시: API 엔드포인트가 인터넷에서 이미지를 가져오기 위해 URL을 받아들입니다. 악의적인 사용자가 http://169.254.169.254/latest/meta-data/ (클라우드 환경에서 일반적인 메타데이터 엔드포인트)와 같은 URL을 제출합니다. 서비스는 이를 이미지로 생각하고 URL을 가져오지만, 대신 IAM 역할, 비밀 키, 또는 기타 내부 구성 세부 정보와 같은 민감한 데이터를 검색합니다. 공격자는 이 정보를 권한 상승이나 데이터 유출과 같은 추가 공격에 사용합니다.
권장 사항:
- 입력 검증 - 항상 입력을 검증하고 정제하세요. 신뢰할 수 없는 소스에서 전체 URL을 받아들이지 마세요. APISIX를 사용하여 uri-blocker 플러그인을 설정하여 내부 리소스에 대한 차단 규칙을 적용할 수 있습니다.
- 화이트리스트 - 알려지고 신뢰할 수 있는 도메인이나 IP에만 연결을 허용하세요. APISIX의 ip-restriction 플러그인을 사용하거나 referer-restriction을 활성화하여 허용 가능한 도메인이나 URL 패턴의 화이트리스트를 설정할 수 있습니다. 화이트리스트와 일치하지 않는 URL은 거부됩니다.
- 네트워크 분할 - 서버가 분할되어 있고 민감한 내부 리소스가 직접 접근할 수 없도록 하세요.
8. 보안 설정 오류
위협: 이는 API가 안전하게 구성되지 않아 민감한 정보가 노출되거나 불필요한 권한이 부여될 때 발생합니다. 예를 들어, 서버 세부 정보를 노출하는 오류 메시지 로깅, 불필요한 HTTP 메서드 활성화, 또는 기본 자격 증명이 변경되지 않은 경우가 있습니다.
예시: 간단한 예로, API가 실수로 .git 디렉토리를 노출하여 소스 코드와 커밋 기록을 노출시킬 수 있습니다. 또 다른 예로, 악의적인 사용자가 플랫폼을 사용 중에 오류 메시지를 만납니다. 일반적인 오류 메시지 대신, 데이터베이스 구조, 소프트웨어 버전, 파일 경로를 노출하는 상세한 스택 트레이스를 보게 됩니다. 이 정보를 사용하여 플랫폼의 잠재적인 취약점을 식별합니다. 또한, 이러한 플랫폼에 대한 일반적인 설정 오류를 조사한 후, 테스트 계정으로 로그인을 시도하고 성공하여 관리자 접근 권한을 얻습니다.
권장 사항:
- 정기적인 감사 - 정기적으로 구성을 검토하고 업데이트하세요. 일반적인 설정 오류를 스캔하기 위해 자동화된 도구를 사용하세요. APISIX의 로깅 플러그인을 사용하면 모든 접근 및 시스템 활동이 기록됩니다. 반복된 로그인 실패나 제한된 엔드포인트에 대한 접근과 같은 비정상적인 활동은 검토를 위해 플래그가 지정될 수 있습니다.
- 최소 권한 원칙 - 필요한 권한만 부여하고 과도하게 허용적인 설정을 피하세요.
- 기본 보안 헤더 - APISIX는 Content Security Policy (CSP) 및 HTTP Strict Transport Security (HSTS)와 같은 필수 보안 헤더를 설정하여 안전한 기본값을 시행합니다. 이는 특정 웹 기반 공격의 위험을 줄입니다.
- 오류 마스킹 - 오류 메시지가 일반적이고 민감한 정보를 누출하지 않도록 하세요. APISIX는 응답 재작성 플러그인이나 사용자 정의 데이터 마스크 플러그인을 사용하여 상세한 오류 메시지를 마스킹하도록 구성할 수 있습니다.
9. 부적절한 인벤토리 관리
위협: 조직이 성장함에 따라, 특히 중앙 집중식 관리가 없는 경우, 모든 API를 추적하지 못할 수 있습니다. 이는 잊혀지거나, 오래되거나, 보호되지 않은 API가 악용될 수 있게 합니다.
예시: 여러 버전의 API가 모니터링되지 않은 채로 남아 있는 경우가 흔합니다. 공격자는 오래된 API 버전이나 패치되지 않은 접근 지점을 대상으로 할 수 있습니다. 또한, 제3자 연결의 취약점을 통해 무단 접근을 얻을 수 있습니다.
권장 사항: APISIX의 Admin API를 사용하여 더 이상 필요하지 않은 경로를 정기적으로 검토하고 비활성화하며, 모든 API 버전을 클라이언트 앱에 방해 없이 추적할 수 있습니다. API7 Portal은 모든 API를 모니터링하고 관리할 수 있는 중앙 집중식 관리 대시보드를 제공합니다. 오래된 버전의 API가 여전히 실행 중이고 더 이상 사용되지 않는 경우, 대시보드를 통해 이 API를 식별하고 백엔드 서비스 자체에서 코드 변경 없이 종료할 수 있습니다.
10. API의 안전하지 않은 소비
위협: 제3자 API를 통합하거나 내부 API를 소비할 때 안전하게 수행되지 않으면, 상위 API에 존재하는 취약점에 애플리케이션이 노출될 수 있습니다.
예시: 사용자가 심박수, 수면 패턴, 신체 활동과 같은 건강 지표를 모니터링할 수 있는 모바일 애플리케이션을 생각해보세요. 이 애플리케이션은 이러한 제3자 API를 소비할 때 엄격한 검증과 보안 검사를 수행하지 않습니다. 공격자는 통합된 영양 추적 API 중 하나가 취약하며 악성 데이터를 반환할 수 있음을 식별합니다. 애플리케이션이 이 API에서 식단 계획 제안을 가져올 때, 악성 페이로드를 검색하고 처리하여 잠재적인 데이터 유출이나 애플리케이션 오작동을 초래할 수 있습니다.
권장 사항: 제3자 API를 통합하기 전에 신뢰할 수 있는 소스에서 왔는지, 보안 평가를 거쳤는지 확인하세요.
- 오류 처리 - 소비된 API의 예기치 않은 응답이나 동작을 취약점을 노출하지 않고 처리하세요.
- 데이터 검증 - 제3자 API에서 받은 데이터를 항상 검증하고 정제하세요. APISIX는 웹 애플리케이션 방화벽 (WAF)과 통합하여 제3자 API에서 들어오는 데이터를 검사하고 필터링할 수 있습니다. 이는 알려진 악성 패턴이나 페이로드를 탐지하고 차단할 수 있습니다. 또한, 내부 네트워크를 통해 이동 중인 트래픽의 보안을 보장하기 위해 TLS/mTLS를 활성화할 수 있습니다.
요약
OWASP API 2023에서 제안한 보안 지침을 적용하면 API를 보호하기 위한 기초를 마련할 수 있습니다. APISIX 게이트웨이 기능을 사용하면 이 과정을 단순화하고 OWASP 권장 방어 메커니즘을 구현하는 비용을 크게 줄일 수 있습니다.