보안이 취약한 API는 기업의 명성을 바다로 휩쓸어 버릴 수 있습니다.

일반적으로 삶에서 소통은 매우 중요한 가치입니다. 이해를 구하고, 새로운 것을 배우며, 관계를 형성하는 데 소통보다 빠른 방법은 없습니다. 소프트웨어 분야에서 API는 애플리케이션 간의 대화를 가능하게 하여 기능과 사용성을 높이는 소통의 역할을 합니다. 이러한 연결성은 최종 사용자가 선호하는 풍부한 경험을 제공하며, 오늘날 소프트웨어에서 필수적으로 기대하는 요소가 되었습니다.

하지만 현실과 마찬가지로, 너무 많은 대화는 큰 문제를 야기할 수 있습니다. 최근 Experian은 제3자 파트너가 사용하는 API 중 하나가 잠재적으로 유출되어 거의 모든 미국 시민의 신용 점수가 노출되는 뼈아픈 경험을 했습니다.

문제는 신속하게 패치되었지만, 이 취약점이 완전히 차단되었는지에 대해서는 여전히 의문이 남습니다. 한 공급업체가 영향을 받았다면 다른 곳도 영향을 받았을 가능성이 크며, 이는 해당 보안되지 않은 API를 사용하는 모든 이에게 영향을 미치는 시스템적 버그일 수 있습니다.

API 보안은 대부분의 보안 전문가들이 항상 염두에 두고 있는 문제이며, 우리는 이에 대응할 지식을 갖춰야 합니다.

허술한 API 인증은 누구나 쉽게 우회할 수 있습니다

많은 데이터 유출, 침해 및 보안 사고의 특징은 거창한 계획이 필요하지 않다는 점입니다. SolarWinds 사례처럼 복잡하고 교묘하며 파괴적인 공격은 천재적인 사이버 범죄 조직이 수행해야 가능하며, 이는 일반적인 경우라기보다 예외적인 사례에 가깝습니다.

API가 취약한 인증 방식으로 구축되면 공격자가 악용하기 매우 쉽습니다. Experian의 API 버그를 발견한 보안 연구원 빌 데미르카피(Bill Demirkapi)는 해당 API가 인증 없이도 접근 가능하다는 점을 확인했습니다. 생년월일 필드에 '00/00/0000'을 입력하는 것만으로도 이름과 우편 주소 같은 공개 정보를 사용하여 타인의 신용 점수를 확인할 수 있었습니다. 아직 보고된 바는 없지만, 이러한 기록이 수집되어 신용 관련 데이터 덤프로 가공될 잠재적 위험은 분명히 존재합니다.

사용 사례의 규모와 관계없이 깨끗하고 기능적인 인증 프로세스를 갖춰야 합니다. 제대로 보안되지 않은 채 여러 시스템에 대한 접근을 허용할 수 있는 API는 큰 위험 요소입니다.

인증 파괴(Broken Authentication)는 OWASP API 보안 상위 10대 취약점 중 2위에 해당합니다. 이곳에서 이 버그를 방지하는 방법을 자세히 알아보고, 학습 후 저희 플랫폼에서 실력을 테스트해 보세요.

부실한 API 보안 통제는 문화적 변화가 필요한 광범위한 문제입니다

Experian과 같은 조직만을 탓하는 것은 공정하지 않지만, 이번 API 노출에서 드러난 보안 통제에 대한 세심함 부족은 IT 시스템 및 엔드포인트의 일부로 API를 운영하는 수많은 기업에게 경종을 울립니다.

전반적으로 우리는 API 취약점을 발견하고 수정하는 것을 넘어, 이를 우리가 보호해야 할 공격 표면의 일부로 이해하는 데 더 많은 노력을 기울여야 합니다. API의 구축 방식에 대한 가시성은 매우 중요한 문제이며, 보안 모범 사례의 일부로 요구되어야 합니다. 가장 엄격한 보안 조치를 갖춘 조직이라도 기업 보안 통제 범위 밖에서 운영되는 API로 인해 무너질 수 있습니다. API의 출처가 어디인지, 최종 관리자가 누구인지(제3자 공급업체인가요? 보안 수준은 어느 정도인가요?), 어떤 정보에 접근하는지 확인하는 것이 그 어느 때보다 중요합니다.

인젝션 취약점은 모든 CISO의 골칫거리입니다.

API 보안은 보안 프로그램에 포함된 비교적 새로운 모듈처럼 보일 수 있지만, 기존 웹 소프트웨어에서 흔히 보던 (매우) 오래된 수법으로 악용될 수 있습니다.

최근 공개된 Accellion 공격 사례는 SQL 인젝션과 OS 명령 실행 공격이 결합되어 공격자가 API를 조작하고 주민등록번호를 포함한 방대한 민감 데이터를 탈취했음을 보여줍니다. 공격자들은 Accellion의 FTA 소프트웨어에 대한 광범위한 지식을 가지고 있었으며, 이는 상당한 수준의 리버스 엔지니어링을 통해 가능했을 것으로 판단됩니다.

2020년 12월부터 2021년 1월까지 이어진 침해 사고 동안 공격자들은 충분한 피해를 입힐 시간이 있었습니다. 2021년 2월 추가 조사 결과, 저장형 XSS 취약점이 발견되었습니다. 포렌식 분석에 따르면 단 하나의 API 엔드포인트에서 사용자 입력을 제대로 검증하지 않아 admin.pl 스크립트를 호출할 때 인자를 주입할 수 있었던 것으로 밝혀졌습니다.

유명 교육 기관을 포함한 3,000개 이상의 고객사를 둔 이번 침해 사고는 그 영향력이 매우 클 수 있습니다. 안타까운 점은 이러한 공격이 보안을 의식하는 개발자라면 프로덕션 이전 단계에서 코드 수준으로 해결할 수 있었던 일반적인 취약점을 악용했다는 것입니다. 반복해서 확인하듯, 열려 있는 작은 창문 하나가 큰 문제를 일으킬 수 있습니다. 인간이 주도하는 사이버 방어 문화를 구축하는 것이 이러한 인간적인 문제를 해결하는 전략의 일부가 되어야 합니다.

지금 바로 Java Spring API, Kotlin Spring API, C# (.NET) Web API 등에서 API 보안 실력을 테스트하고 싶으신가요? 학습 플랫폼에서 API 챌린지에 도전해 보세요(드롭다운 메뉴를 통해 모든 언어와 프레임워크를 확인하세요):
‍

‍