안녕하세요 HN! 저희는 Escape (https://escape.tech)의 공동 창업자인 Tristan과 Antoine입니다. 저희는 체스에서 영감을 받은 AI를 사용하여 보안 엔지니어와 개발자가 조직에서 생성한 API를 발견하고 보호할 수 있도록 돕습니다.

저희의 데모는 여기 있습니다:

전형적인 현대의 대규모 조직은 수백 개, 많게는 수천 개의 API를 보유하고 있으며, 그중 상당수는 민감한 데이터를 처리하거나 비즈니스 운영에 매우 중요합니다. 이러한 API의 개발은 여러 개발 팀에 분산되어 있으며, 이들이 항상 API 보안 모범 사례 (best practices)에 대한 지식을 갖추고 있는 것은 아닙니다. API 소스 코드 (source codes)는 빈번하게 업데이트되므로, 프로덕션 환경 (production environments)에 새롭고 쉽게 악용될 수 있는 보안 취약점 (security vulnerabilities)이 도입되기 쉽습니다 (2018년 FB 5천만 계정 데이터 유출 사건을 생각해보세요).

API는 전 세계 웹 트래픽의 80%를 차지하며, 이 비중은 계속 증가하고 있습니다. API를 보호할 책임은 보통 API 개발자가 아닌 조직의 보안 엔지니어에게 주어지는데, 이는 보안 엔지니어가 보안 방법을 알고 있기 때문에 타당한 조치입니다. 하지만 실제로 이는 거의 불가능한 작업입니다. 보안 엔지니어는 개발자들이 온라인에 노출하는 모든 것을 추적할 방법이 없으며, 대개 그들에게 이를 알려주는 사람도 없기 때문입니다! 그리고 설령 알게 되더라도, 이를 달성하기 위한 적절한 툴링 (tooling)이 부족합니다. 이는 조직에게는 거대한 리스크이며, 보안 엔지니어에게는 고통이자 개인적인 리스크이며, 또한 훌륭한 기술적 도전 과제입니다.

몇 년 전 소프트웨어 엔지니어로 일할 당시, 저는 데이터 보안 사고를 겪었습니다. 한 제약 회사 고객사의 데이터가 NoSQL 인젝션 (NoSQL injection)으로 인해 유출된 사건이었습니다. 이 경우에는 피해가 통제 가능한 수준에서 마무리되었지만, 사이버 범죄자들이 보안 취약점을 악용했다는 이유만으로 어느 날 자고 일어났을 때 애플리케이션의 모든 데이터가 사라져 있을 수도 있다는 악몽 같은 생각을 하게 되었습니다. 개발자들이 프로덕션 (production) 환경에 배포하는 것이 안전한지 확인할 수 있는 솔루션을 찾으려 노력했지만, 특별히 괜찮은 것을 찾을 수 없었습니다. OWASP ZAP과 같은 보안 스캐닝 (security scanning) 도구들은 침투 테스트 (penetration testing) 배경 지식을 가진 사람들을 위해 설계되었습니다. 코드 스캐닝 (code scanning) 도구들은 많은 오탐 (false positives)을 대가로 아주 쉬운 문제들 (low-hanging fruit)만 찾아냈고, 결국 보안 중심의 린터 (linters)와 비슷해져서 아주 미미한 가치를 위해 IDE 전체를 빨간색으로 물들여 버렸습니다. 기존의 어떤 보안 도구도 실제 엔지니어를 염두에 두고 만들어지지 않은 것 같았습니다.

이전에 NATO와 Apple에서 보안 엔지니어로 근무했던 Antoine을 만났을 때, 우리는 이 문제를 함께 해결하고 개발자와 보안 담당자 모두에게 매력적인 현대적인 보안 도구를 만들기로 결정했습니다. 이 도구는 빨라야 하고, 설정이 쉬우면서도 구성 가능해야 하며, API 보안에 대한 탁월한 지원을 갖추고, 낮은 오탐 (false positive) 비율로 관련 있는 것들을 찾아내야 했습니다.

첫 번째 단계는 보안 엔지니어와 개발자들에게 어떤 API를 보호해야 하는지 보여주는 것이었습니다. 우리는 조직의 노출된 API와 내부 API를 발견할 수 있는 쉬운 방법을 찾아야 했습니다.

모든 API를 발견하기 위해, 우리는 도메인, 프론트엔드 웹사이트, 그리고 SPA (Single Page Applications)를 스캔하여 조직이 노출하는 모든 API 경로를 추출하는 시스템을 설계했습니다. 그런 다음 코드 저장소 (Code Repositories), API 게이트웨이 (API Gateways), 그리고 API 개발 도구에 연결하여 이 데이터를 보강함으로써, 노출된 모든 엔드포인트 (Endpoints)의 전체 목록과 해당 엔드포인트가 처리하는 데이터의 민감도를 생성합니다. 다른 테스트 도구들은 조직에 의해 노출된 모든 API 경로에 대한 인벤토리 (Inventory)를 제공하지 못하지만, 앞서 언급했듯이 보안 엔지니어가 직면하는 가장 큰 문제는 종종 무엇을 테스트해야 하는지 알아내는 것 그 자체입니다!

그다음으로, 우리는 보안 엔지니어와 개발자에게 API의 보안 이슈 목록을 제공해야 했습니다.

API는 비즈니스 모델 레이어 (Business Model Layer)로 작동하기 때문에, 대부분의 치명적인 보안 이슈는 API의 기반이 되는 비즈니스 프로세스 (Business Processes)에 존재합니다. 보안 분야에서 비즈니스 프로세스를 깨뜨림으로써 발생하는 이슈들을 BOLA (Broken Object Level Authorization), BFLA (Broken Function Level Authorization), 그리고 BOPLA (Broken Object Property Level Authorization)라고 부릅니다.

이러한 이슈들을 찾기 위해, 우리는 퍼징 (Fuzzing)과 같은 전통적인 기술에 의존할 수 없다는 것을 알고 있었습니다. 우리는 API의 기반이 되는 비즈니스 프로세스를 모델링하고 이를 깨뜨리려는 시도를 할 방법을 찾아야 했습니다.

이 주제에 대해 연구하면서, 우리는 체스 (Chess)나 바둑 (Go)과 같은 보드게임과 유사한 방식으로 API 비즈니스 프로세스를 모델링하는 것이 놀라울 정도로 잘 작동한다는 것을 발견했습니다. 근본적인 이유는 간단합니다. 보드게임은 상태 머신 (State Machine)이며, 게임의 상태를 변경하기 위해 규칙을 준수해야 하는 액션 (Actions)을 실행할 수 있기 때문입니다. 체스 게임에서 기물을 움직이는 것을 생각해 보세요. 각 기물은 고유한 움직임을 가지고 있으며, 보드 위의 위치는 상태를 나타냅니다.

API도 이와 유사합니다. API는 내부 상태를 나타내는 데이터베이스 (Database)와, 그 상태에서 실행할 수 있는 액션을 나타내는 API 경로를 가지고 있습니다. 물론 대부분의 API는 체스 기물의 수보다 훨씬 더 많은 경로를 가지고 있기 때문에 체스 게임보다 더 복잡합니다. 수학적으로 표현하자면, 액션 공간 (Action Space)이 훨씬 더 크다고 할 수 있습니다.

하지만 모델들이 충분히 유사하기 때문에, Go와 같이 액션 공간 (Action Space)이 큰 게임의 맥락에서 효과가 입증된 알파-베타 (alpha-beta), 몬테카를로 트리 탐색 (Monte-Carlo Tree Search), 그리고 더 발전된 머신러닝 (Machine Learning) 기법들을 적용해 볼 수 있습니다.

이러한 것들이 저희의 자체 알고리즘인 피드백 기반 API 탐색 (Feedback-Driven API Exploration, FDAE)의 기초가 되는 아이디어였습니다. FDAE는 기저에 깔린 비즈니스 프로세스를 자동으로 식별하고, 특히 이를 무너뜨리는 것을 목표로 하는 API 요청 시퀀스를 생성하여 잠재적인 보안 결함과 데이터 유출을 찾아냅니다.

FDAE는 API의 경로 (Routes) 및 파라미터 (Parameters) 목록을 입력받는 것으로 시작합니다. 먼저 개인정보 (PII)나 금융 정보와 같은 민감한 데이터로 이어지는 경로와, 다양한 종류의 인젝션 (Injection) 및 공격에 취약할 가능성이 가장 높은 파라미터를 식별합니다.

종종 이러한 경로들은 UUID나 도메인 특화 값과 같은 파라미터를 필요로 합니다. 바로 이 지점에서 전통적인 보안 스캐너들이 한계를 드러냅니다. 이들은 흔히 손쉬운 인젝션 취약점을 찾기 위해 파라미터들을 무작위로 퍼징 (Fuzzing)하지만, 결국 데이터 검증 계층 (Data Validation Layer)에서 차단되고 맙니다.

FDAE는 더 똑똑합니다. 만약 /user/:uuid 경로가 민감할 수 있다고 감지하면, 먼저 API 내의 다른 모든 경로를 살펴보고 유효한 사용자 UUID를 반환하는 경로를 찾으려고 시도합니다. 일단 유효한 사용자 UUID를 확보하면, 이를 사용하여 /user/:uuid 경로를 트리거하고 다양한 방식으로 이를 악용(Exploit)하려고 시도합니다.

만약 데이터베이스에 기존 사용자가 없더라도 사용자를 생성하는 경로가 있다면, Escape의 FDAE는 사용자를 생성하고 그 UUID를 얻은 다음, 사용자 UUID를 요구하는 경로들을 공격하는 시도까지 할 수 있습니다.

인간 침투 테스터 (Penetration Testers)와 버그 헌터 (Bug Hunters)가 수행하는 방식과 매우 유사한 이 프로세스를 통해, Escape는 모든 API와 비즈니스 프로세스에 대해 광범위하고 심도 있는 테스트를 수행할 수 있습니다. 이는 특히 테넌트 격리 (Tenant Isolation) 문제, 복잡한 다단계 인젝션 (Multi-step Injections), 요청 위조 (Request Forgeries)와 같은 수많은 접근 제어 (Access Control) 버그를 찾는 데 탁월합니다.

구체적인 예를 들자면, 여러분이 이커머스 (e-commerce) 애플리케이션을 구축하고 있다고 가정해 봅시다. Escape는 사용자가 결제 단계를 우회하거나, 요청 (request) 내의 입력 파라미터 (input parameters)를 수정하여 다른 사용자의 주문 정보나 개인 정보에 접근할 수 있는 사례를 탐지할 수 있습니다.

피드백 기반 API 탐색 (Feedback Driven API Exploration)이 어떻게 작동하는지에 대한 더 자세한 설명과 그래픽은 여기에서 확인할 수 있습니다: https://escape.tech/blog/feedback-driven-api-exploration/

Escape의 전체 스캐닝 (scanning) 프로세스는 몇 분밖에 걸리지 않습니다. 이전 개발자로서 저희에게는 CI/CD 파이프라인 (pipelines)에 API 테스트를 원활하게 통합하고 관련 수정 사항을 빠르게 구현하는 것이 매우 중요했습니다. 이것이 확장 가능한지 검증하기 위해, 저희는 인터넷상의 모든 공개 API (public APIs)를 스캔하여 그 품질에 대한 연구 보고서를 작성했습니다: GraphQL 보안 현황 (The State of GraphQL Security, https://26857953.fs1.hubspotusercontent-eu1.net/hubfs/268579...), 그리고 공개 API 현황 (The State of Public APIs, https://apirank.dev/state-of-public-api-2023/).

몇 분 만에 API를 발견하고 테스트하는 것 외에도, 저희는 Escape를 실행 가능한 (actionable) 도구로 만들고 싶었습니다. 문제를 정확히 짚어내는 것도 중요하지만, 그렇다면 어떻게 수정해야 할까요? 대부분의 동적 스캐너 (dynamic scanners)는 모호한 해결 지침을 제공합니다. Escape는 개발자를 돕기 위해 실제로 코드 스니펫 (code snippets)을 생성합니다.

저희는 조직 내 API 및 개발자 수를 기준으로 몇 가지 월간 및 연간 구독 플랜을 제공하며, 7일간의 무료 체험을 제공합니다. 가격은 체험 기간 중 앱 내에서 확인할 수 있습니다. 저희 제품은 매우 기술적이므로, 사용자가 결정을 내리기 전에 기능을 탐색하고, Escape가 무엇을 하는지 평가하며, 그 가치를 이해할 수 있도록 하고 싶었습니다. 사용자는 제품에 대한 이해도가 높아져 가장 적절한 시점인 체험 과정 중에 가격 상세 정보를 확인할 수 있습니다. 신용카드 없이도 https://escape.tech 에서 저희를 체험해 보실 수 있습니다.

저희의 주요 SaaS 제품은 클로즈드 소스 (closed source)이지만, 보안 전문가와 개발자들을 위해 https://github.com/Escape-Technologies/ 에 많은 오픈 소스 (open source) 패키지를 공개하고 있습니다. 그중 일부는 GraphQL Armor (https://github.com/Escape-Technologies/graphql-armor/)와 같이 널리 사용되고 있습니다.

API의 수와 복잡성은 끊임없이 증가하고 있으며, 저희 또한 매일 계속해서 배우고 있습니다. 따라서 여러분의 피드백(크고 작음에 상관없이!)을 간절히 기다리고 있으며, 보내주신다면 매우 감사하겠습니다! 감사합니다!