Introduction
Web API는 웹에서 사용 또는 웹을 기반으로 사용되는 API를 의미합니다. 기본적으로 웹에서 사용되는 API라고 알려져 있지만 모바일, IoT 등 다른 디바이스나 플랫폼에서도 Web을 기반으로 한 API가 많이 사용되고 있어 API란 말로도 통용됩니다.
원래 API란 말은 Application Programming Interface 약자로 프로그래밍 인터페이스를 의미하기 때문에 단순히 웹 페이지만 아닌 모든 Interface를 의미합니다. 다만 요즘은 API == Web API의 느낌으로 많이 사용됩니다.
Threat
- Web Hacking
- Broken Authorization
- Broken Authentication
- Data Exposure
Security Considerations
Tolerance to attack
Web API는 HTTP 프로토콜을 기반으로 하기 때문에 웹 해킹 기술에 전반적으로 영향을 받습니다. 외부에서 전달받는 값(헤더, 쿠키, Body 등)들을 처리할 때에는 이를 신뢰하지 않고 개발자가 예측 가능한 범위에서만 값을 받고 처리할 수 있도록 검증해야합니다.
Web API 상에선 Injection(e.g SQLi), IDOR, SSRF 등 서버향의 공격이 영향 범위에 많이 들어가게 됩니다.
AAA (Triple-A)
API의 보안을 챙기는데 있어 AAA 또한 좋은 관점으로 사용됩니다. OpenAPI가 아닌 API를 구성할 땐 필수적으로 고려해야할 요소들입니다.
AAA refers to Authentication (to identify), Authorization (to give permission) and Accounting (to log an audit trail). It is a framework used to control and track access within a computer network.
Authentication
Authentication는 신원을 증명하고 식별하는 과정입니다. 이를 통해 허용된 누가 API를 사용했는지 체크하고 알 수 있습니다. 불특정 다수에게 공개되는 OpenAPI를 제외하곤 사용자 추척이나 쿼터 체크 목적으로도 사용됩니다.
이러한 신원을 증명하는 과정이 API를 사용하는 플로우 내 포함될 수 있으며, 해당 부분은 굉장히 중요한 보안 요소가 됩니다.
Authorization
Authorization은 권한을 체크하는 과정입니다. API Key 등을 발급하고 검증 시 권한의 폭을 제한하여 키에 맞는 권한이 사용될 수 있도록 검증합니다.
- Key1: Admin Role
- Key2: User Role
Accounting (Audit trail)
API를 사용한 흔적인 순차적으로 기록될 수 있어야합니다. 이는 보안 이슈가 발생했을 때 원할하게 사태를 파악할 수 있을 뿐만 아니라 API의 부정 사용을 감지하고, 클라이언트의 부인방지 목적으로도 사용될 수 있습니다.
Access Control
API는 용도와 목적에 따라 적절한 Access Control 설정이 필요합니다.
- API Key
- IP Based ACL
API Key Security
API의 보안성, 사용량 측정 등의 목적으로 각 Client 마다 사용할 수 있는 API Key라는 개념이 있습니다. 보통 X-API-Key, Authorization 등의 헤더를 통해 전달하는 경우가 많으며 API Key는 적절한 레벨의 권한과 파워를 가지고 있어야 합니다.
Key Scope
API Key의 Scope는 동일한 레벨의 권한에서 얼마나 많은 범위에 접근할 수 있는지를 의미합니다. 가급적이면 필요한 만큼의 범위를 제공하는게 좋고 이러한 경우 키 탈취, 노출 등의 상황에서 피해 범위를 리스크를 줄일 수 있습니다.
Github의 토큰 또한 디테일하게 Scope를 명시할 수 있습니다.
Key Power
API 키가 여러 역할의 기능을 수행하는 경우, 즉 파워가 강한 경우 키 탈취에 대한 리스크도 크게 만듭니다. 하나의 키가 여러 레벨의 권한에서 사용된다면 가진 힘에 비해 탈취될 가능성도 높습니다. 그래서 API Key가 요구하는 기능에 따라 적당한 파워 설정과 키의 분리가 필요합니다.
With great power comes great responsibility Ben Parker
Github의 토큰에선 Admin에 대한 권한도 분리되어 관리됩니다.
Entropy
API Key는 쉽게 추측하거나 Bruteforce, Dictionary attack 등으로 깨지지 않도록 적절한 엔트로피를 가져야합니다. 특정 단어나 의미 등으로 구성된 값 보단 난수 계통의 값이 안전하며 길이가 길 수록 엔트로피가 높아져 크랙 등에 강해집니다.
# Weak (MD5)
X-API-Key: 3088e26e9d077fba484c3280d800db24
# More Secure (SHA256)
X-API-Key: ffdb697605ece10e7dd1d95ff45763788d60a896bf24346512faf72ce285d1c9
# UUID
X-API-Key: 34cbbeba-b24d-4a06-b0e5-3799a112e500
Entropy of ~330 bit / https://www.hahwul.com/phoenix/session/
Key Management
API Key는 한번의 키 생성으로 쭉 사용하는 것이 아닌 특정한 주기나 이슈 등에 의해 재 생성, 폐기될 수 있어야 합니다. 프로그램을 통한 기능이던, 절차던 아래 역할은 수행할 수 있는 요건을 갖추는게 좋습니다.
- API Key 생성
- API Key 재생성
- API Key 폐기
Client Security
API를 사용하는 클라이언트의 위치, 신뢰에 따라서 보안 구성은 달라집니다. 클라이언트가 신뢰받는 위치에 있는지 확인하고 이에 따라서 보안적인 장치들을 구성해야 합니다.
Trusted Client
신뢰받는 클라이언트는 보통 허용된 구간, 디바이스에서만 접근할 수 있는 클라이언트를 의미합니다. 신뢰받는 서버에 API Key를 저장하고 사용하는 형태 등이 해당되며, 이러한 경우 Key rotation 등의 요구조건을 필요할 수 있지만, 한번 발급한 키를 재사용하고 스토리지에 유지하는 형태도 사용할 수 있습니다. 상대적으로 신뢰받지 않는 클라이언트 보다 약간 보안 정책을 가질 수 있습니다.
Untrusted Client
신뢰받지 못하는 구간에 존재하는 API Key들이 있습니다. 대표적으로 Mobile Device, Javascript API Key 등 누구나 또는 분석을 통해 볼 수 있는 구간에서 호출하는 클라이언트들로 API Key의 유출 가능성이 있기 때문에 용도에 따라 적절한 Scope와 Power 설정이 필요합니다.
또한 Key를 얻기 위해 인증하는 절차(로그인 등)등이 추가로 있다면 좋고 Key rotation 또한 Trusted Client 보다 짧은 주기를 가져야합니다.
Lack of Resources / Rate Limit
API를 통해 얻어갈 수 있는 데이터의 제한이 필요하며 반복 요청 등에 대한 내성도 가지고 있어야합니다. 이는 API를 어뷰징하는 요소부터 이를 기반으로한 DOS, Race condition 등의 공격을 예방하는데 효과적입니다.
OWASP API Security Top 10
OWASP에선 API Security에 대한 Top 10도 제공하고 있습니다. 이 내용이 전부는 아니지만 API의 보안성을 챙기는데 있어 좋은 관점을 주기 때문에 알고 있는게 좋습니다.
- API1:2019 Broken Object Level Authorization
- API2:2019 Broken User Authentication
- API3:2019 Excessive Data Exposure
- API4:2019 Lack of Resources & Rate Limiting
- API5:2019 Broken Function Level Authorization
- API6:2019 Mass Assignment
- API7:2019 Security Misconfiguration
- API8:2019 Injection
- API9:2019 Improper Assets Management
- API10:2019 Insufficient Logging & Monitoring