- API(Application Programming Interface)
> 여러 프로그램들과 데이터베이스, 그리고 기능들의 상호 통신 방법을 규정하고 도와주는 매개체
| API 유형 | |
| REST API (REpresentational State Transfer) |
- HTTP로 하이퍼 미디어 콘텐츠를 전송하기 위한 하나의 아키텍처 스타일 - 6가지 원칙: 통일된 인터페이스, 클라이언트-서버 구조, 상태 없음(Stateless), 캐시 가능(Cacheable), 계층화 시스템, 주문형 코드 - 단순하기 때문에 현재 가장 널리 쓰이는 API - 단일한 표준 REST 구조 없음, 큰 페이로드, 데이터 과다/과소 가져오기 등 단점 - 데이터 지향형 |
| GraphQL API | - 데이터 처리 부담을 서버로 옮김으로써 REST QPI의 데이터 과다/과소 가져오기 문제를 해결 - 장점: 정교한 질의 가능, 중첩, 강 타입 적용, 발견성 - 단점: DoS에 취약, 필요 이상의 많은 데이터 노출 - 데이터 지향형 |
| RPC API (Remote Procedure Call) |
- 클라이언트는 Stub 라이브러리를 이용해 네트워크로 전송되며, 서버는 호출 정보를 복원한 후 서버 쪽 Stub에서 프로시저 실행 및 결과 반환 - 특정 작업을 원격으로 실행해야 하는 명령 지향적 응용 프로그램들에서 주로 쓰임 - 동작 지향형 |
| SOAP API (Simple Object Access Protocol) |
- 서비스 지향적인 XML 기반 웹 통신 프로토콜로, 표준화되어 있음 - 뛰어난 확장성 - 복잡한 구현과 큰 데이터 페이로드 |
| WebSocket API | - 웹 소켓 통신 프로토콜에 기반한 API |
| API 데이터 형식 | |
| XML (eXtensible Markup Language) |
- 자료형(데이터 타입)과 독립적 - 내용과 표현을 분리하도록 설계 - 확장성 - 복잡성과 큰 용량 문제로 많이 쓰이지는 않음 |
| JSON (JavaScript Object Notation) |
- 데이터는 키-값 쌍들로 표현 - 키는 항상 문자열이므로 큰따옴표로 감싸야 하며, 값은 정수, 부울형, 문자열 또는 널 값 |
| YAML (YAML Ain't Markup Language) |
- JSON의 불편함(주석 지원 X, 유연하지 않은 문법 등)을 해소하기 위해 만들어짐 |
| OAS (Open API Specification-명세) |
- API의 행동을 정의하기 위한, 사람이 읽기 쉬운 표준 규격으로, 개방형 표준 - OAS에 따라 API를 정의할 때는 YAML, JSON 모두 사용가능 - OAS 정의서부터 만든 후 API 개발 및 운영을 진행하는 방식을 설계 우선 접근 방식 |
- API는 데이터 접속의 표준화 및 편의성, 자동화와 확장성 등 많은 장점을 제공
- 그러나, API는 공격자에게도 인기가 많음
① 타 시스템과의 상호 연결을 위해 공용 네트워크에 노출된 경우가 많아 공격자 발견 및 접근에 용이
② 개발 및 통합을 위해 문서화가 잘 되어있어 공격자가 API 작동 방식을 파악하는데 용이
③ 스크립트나 전용 도구를 이용해서 손쉽게 공격을 자동화할 수 있음
④ API는 핵심 데이터 자산에 대한 접근을 제공하기 위한 것으로, 공격자의 관심을 끌 수 있는 데이터
⑤ 기존 보안 도구들은 API 보안에 적합하지 않음
- OWASP는 2019년 API Top 10을 공개 후 2023년 목록을 갱신 [1]
| OWASP API Security Top10 2023 | |
| API1:2023 - Broken Object Level Authorization | - API는 개체 식별자를 처리하는 엔드포인트를 노출시키는 경향이 있어 개체 수준 액세스 제어 문제의 광범위한 공격 표면 생성 - 사용자의 ID를 사용하여 데이터 소스에 액세스하는 모든 기능에서 객체 권한 수준을 확인해야 함 |
| API2:2023 - Broken Authentication | - 인증 메커니즘은 종종 잘못 구현되어 공격자가 인증 토큰을 훼손하거나 구현 결함을 악용하여 일시적 또는 영구적으로 다른 사용자의 ID를 탈취할 수 있음 - 클라이언트/사용자를 식별하는 시스템의 기능을 훼손하면 전반적인 API 보안이 손상됨 |
| API3:2023 - Broken Object Property Level Authorization | - API3:2019 과도한 데이터 노출 및 API6:2019 대량 할당을 결합 - 근본 원인인 개체 속성 수준에서 권한 부여 유효성 검사가 부족하거나 부적절한 취약점 - 이에 따라 권한 없는 사람이 정보를 노출하거나 조작할 수 있음 |
| API4:2023 - Unrestricted Resource Consumption | - API 요청을 충족하려면 네트워크 대역폭, CPU, 메모리 및 스토리지와 같은 리소스가 필요 - 이메일/SMS/전화 통화 또는 생체 인식 유효성 검사와 같은 기타 리소스는 API 통합을 통해 서비스 공급자가 사용할 수 있으며 요청량에 따라 비용이 빌생 - 이에 따른 서비스 거부 또는 운영 비용이 증가 가능 |
| API5:2023 - Broken Function Level Authorization | - 계층, 그룹 및 역할이 다르고 관리 기능과 일반 기능이 명확하지 않은 복잡한 액세스 제어 정책은 권한 부여 문제가 될 수 있음 - 이를 악용해 다른 사용자의 리소스 및/또는 관리 기능에 액세스할 수 있음 |
| API6:2023 - Unrestricted Access to Sensitive Business Flows | - 취약한 API는 기능이 자동화된 방식으로 과도하게 사용되면 비즈니스 흐름을 노출 |
| API7:2023 - Server Side Request Forgery | - SSRF 결함은 API가 사용자 제공 URI의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생할 수 있음 - 이를 통해 방화벽이나 VPN으로 보호될 때에도 응용 프로그램이 예기치 않은 대상으로 제작된 요청을 보낼 수 있음 |
| API8:2023 - Security Misconfiguration | - API와 이를 지원하는 시스템은 API를 보다 사용자 정의할 수 있도록 하기 위한 복잡한 구성을 포함 - 잘못된 구성을 하여 다양한 유형의 공격 표면을 노출할 수 있음 |
| API9:2023 - Improper Inventory Management | - API는 기존 웹 애플리케이션보다 더 많은 엔드포인트를 노출하고 있어 적절한 명세가 업데이트 되어야 함 - 더 이상 사용되지 않는 API 버전 및 노출된 디버그 엔드포인트가 생기지 않도록 문서가 관리 및 갱신되어야 함 |
| API10:2023 - Unsafe Consumption of APIs | - 개발자는 사용자 입력보다 서드 파티 API에서 받은 데이터를 더 신뢰하는 경향이 있으므로 더 취약한 보안 표준이 적용될 수 있음 |
- API 보안 목표
> 오용(Misuse), 남용(Abuse)에 대한 고려-자동화된 스크립팅, 봇, 스크래핑 등-정상적인 사용자 활동과 구별이 어려움
> 데이터거버넌스: 통일적인 API 보안 전략에서 꼭 고려할 사항
> 양성 보안 모델: 허용 목록에 미리 등록해둔 정상적 행위자만 API 백엔드에 접근 가능
> 위험 기반 방법론: 위험도 분석에 기반한 API 보안 우선순위 결정
> 접근제어: API에 접근하는 것이 누구인지 확인하는 인증과 누가 API에 접근할 수 있는지를 결정하는 권한 부여