API(애플리케이션 프로그래밍 인터페이스)는 소프트웨어 프로그램 간 통신을 가능하게 하는 관문이 되었습니다. 서로 다른 시스템 간 정보를 전달하는 디지털 다리처럼 작동합니다. API는 앱이 통신하고 협력할 수 있도록 하여 현대 소프트웨어에서 핵심적인 역할을 합니다. API 보안은 이러한 데이터 연결을 무단 접근 및 공격으로부터 보호합니다. 우수한 API 보안 프레임워크는 민감한 데이터를 보호하고, 악의적인 요청을 차단하며, API 접근 권한이 있는 사용자만 사용할 수 있도록 합니다. 기업들이 핵심 서비스를 온라인으로 더 많이 이전함에 따라, 이러한 보호가 오늘날 더욱 중요해졌다는 것은 당연한 일입니다. 이 블로그는 API 보안 위험이 정확히 무엇인지 설명합니다.
간단한 보안 개념, 공격자들이 사용하는 익숙한 위협들, 그리고 이러한 공격을 방지하는 방법에 대해 논의하겠습니다.
API 보안이란 무엇인가요?
API 보안은 다양한 방법/장치를 사용하여 조직의 API와 데이터를 다양한 보안 위협으로부터 보호하는 과정을 의미합니다. 여기에는 API에 대한 접근 권한을 가진 주체를 식별하고, 시스템 간 전송 중인 데이터를 보호하며, API에 발행된 요청이 안전한지 확인하는 작업이 포함됩니다.
API 보안이 필수적인 이유는 무엇인가요?
API 보안은 민감한 사용자 정보와 조직 시스템을 보호합니다. API가 안전하게 유지되는 한, 공격자가 데이터를 훔치거나 시스템에 접근하는 것을 허용하지 않습니다. API가 안전하게 작동할 때 비즈니스에 대한 신뢰는 유지됩니다. 많은 규정 준수 기준도 API가 안전해야 한다고 명시하며, 이를 준수하지 않는 조직은 벌금을 부과받습니다.
API는 자금, 사용자, 회사 기밀을 다루는 비즈니스 시스템을 연결합니다. API 보안이 취약하면 공격자가 침투하여 이러한 데이터를 탈취할 수 있습니다. 이는 조직에 금전적 손실을 초래하고 고객 신뢰를 훼손하며 법적 문제를 야기합니다. API 공격은 매년 증가하고 있어 이러한 엔드포인트 보안을 더욱 중요하게 만듭니다.
14가지 API 보안 위험 및 대응 방안
API는 매일 수많은 보안 위협에 노출됩니다. 이러한 위험은 코드의 기본적인 버그부터 정교한 공격까지 다양합니다. 이러한 위협을 이해하면 보안 팀이 적절한 방어 체계를 구축하기가 더 쉬워집니다. 가장 흔한 API 보안 취약점과 그 해결 방안을 살펴보겠습니다.
1. 손상된 접근 제어
손상된 접근 제어 사용자가 의도된 접근 범위를 벗어난 리소스를 읽거나 수정할 수 있게 합니다. 가장 간단한 예로, 공격자가 URL의 ID를 변경하여 다른 사용자의 데이터를 가져올 수 있습니다. 이는 API가 로그인한 사용자가 요청된 데이터를 조회하거나 업데이트할 권한이 있는지 검증하지 않을 때 발생합니다. 일부 API에서는 공격자가 접근 권한 확인 없이 자신의 역할을 승격하거나 설정을 변경할 수도 있습니다.
손상된 접근 제어를 수정하려면 조직은 모든 API 요청에 대해 사용자 역할을 확인하는 것부터 시작해야 합니다. 누가 어떤 데이터를 볼 수 있는지 정의하고, 데이터 세트 소유자를 참조하여 표시해도 괜찮은지 확인하십시오. 정확한 사용자 권한에 부합하는 일치 토큰을 사용하고, 접근 제어 문제를 찾기 위해 일관된 보안 감사를 수행하십시오.
2. 손상된 인증
API가 사용자 신원을 충분히 강력하게 검증하지 못하면 애플리케이션은 손상된 인증 문제를 겪게 됩니다. 약한 비밀번호나 만료되지 않는 오래된 로그인 토큰은 API에서 가끔 허용될 수 있습니다. 인증이 제대로 작동하지 않으면 공격자는 약한 비밀번호를 무차별 대입 공격(brute force)하여 기존 인증 메커니즘을 우회하고 사용자 데이터를 유출할 수 있습니다.
조직은 강력한 비밀번호 정책과 주요 이벤트 전 2단계 인증을 도입하여 인증 수준을 높여야 합니다. 또한 일정 시간 후 만료되는 로그인 토큰을 구현하고, 반복된 비밀번호 입력 실패 시 사용자 접근을 차단해야 합니다. 더불어 모든 API 요청 시 로그인 토큰을 검증하고, 공격 가능성을 시사하는 비정상적인 로그인 패턴을 모니터링해야 합니다.
3. 데이터 노출
데이터 노출은 조직의 API가 필요한 것보다 더 많은 데이터를 반환할 때 발생합니다. 이는 일반적으로 데이터베이스 필드, 디버깅 데이터 또는 오류 메시지의 시스템 세부 정보를 포함합니다. 특정 필드만 요청되었음에도 응답 객체에 예상된 내용 대신 전체 데이터 객체가 반환될 경우 조직은 문제를 겪을 수 있습니다. 공격자는 이 추가 정보를 정찰 및 추가 공격에 활용합니다.
민감한 데이터 노출을 방지하려면 각 API가 반환해야 할 스키마를 정의해야 합니다. 응답에서 불필요한 세부 정보를 제거하고, 오류 메시지에는 시스템 정보를 포함하지 않아야 합니다. 로그와 응답에서 민감한 정보를 스크러빙하는 기능을 구현하십시오.
4. 리소스 제한
API가 사용자로부터 너무 많은 요청을 받을 때 리소스 제한 문제가 발생합니다. 공격자는 이를 악용하여 서버에 가짜 요청을 보냅니다. 특정 API는 단일 호출로 대용량 페이로드를 요청할 수도 있습니다. 이는 시스템 리소스를 소모하고 실제 사용자에게 서비스 속도 저하 또는 장애를 유발합니다.
조직은 자원 관리를 위해 사용자 또는 IP 기반 요청 제한을 설정해야 합니다. 과도한 호출을 생성하는 URL에 대해 상당한 요청 지연 및 블랙리스트 적용을 구현하십시오. 비정상적인 특성을 보이는 공격 유형의 요청 패턴을 주의 깊게 관찰하십시오.
5. 인젝션 공격
추가 검증 없이 사용자 입력을 신뢰하는 API는 인젝션 공격로 이어집니다. 클라이언트 측에서 공격자는 등록 양식처럼 정상적으로 보이는 페이로드에 숨겨진 특수 명령을 전송합니다. 이러한 명령어/페이로드는 데이터베이스에서 민감한 정보를 유출하거나, 시스템 명령어를 실행하거나, 저장된 데이터를 변경할 수 있습니다. 이는 개발자가 사용자 입력에 대한 입력 정제 및 유효성 검사를 구현하지 않을 때 발생합니다.
조직은 사용 전 모든 입력 데이터를 검사하는 유효성 검사(인젝션 공격 방지)를 구현해야 합니다. "<" 및 ">"와 같은 특수 문자를 차단하여 악성 페이로드를 방지하십시오. 데이터베이스와 통신할 때는 안전한 방법을 사용하십시오. 입력 크기에 제한을 두고 각 API에 대해 허용되는 입력 유형 목록을 유지하십시오.
6. 부적절한 자산 관리
개발 팀이 지속적으로 새로운 기능과 버전을 배포함에 따라 API는 빠르게 진화합니다. 이로 인해 여러 API 버전이 동시에 실행되고, 하위 호환성을 위해 이전 버전이 계속 활성화되는 경우가 많습니다.
개발 팀은 때때로 테스트용 API를 프로덕션 환경에 배포하여 추가적인 보안 위험을 초래하기도 합니다. 이러한 잊혀진, 사용되지 않는, 또는 테스트용 API는 흔히 "섀도우 API" 또는 "좀비 API"라고 불리며, 일반적으로 오래된 코드를 포함하고 최신 보안 통제가 부족합니다. 알려진 취약점과 구식 보안 조치로 인해, 이들은 가장 쉬운 공격 경로를 찾는 공격자들의 주요 표적이 됩니다.
조직의 API를 더 효과적으로 관리하는 한 가지 방법은 API 인벤토리를 활용하는 것입니다. 이는 API의 모든 버전과 실행 위치를 기록합니다. 새 버전이 작동하기 시작하면 구버전을 폐기하세요. 테스트용 API는 테스트 서버에 그대로 두십시오. 모든 API 엔드포인트를 정기적으로 스캔하여 보안 문제를 확인하세요. 네트워크 내 숨겨진/섀도/좀비 API를 식별하는 도구를 활용하십시오.
7. 대량 할당
대량 할당 취약점은 API가 클라이언트가 제공한 데이터를 적절한 필터링 없이 내부 객체나 데이터베이스 레코드에 자동으로 바인딩할 때 발생합니다. API가 업데이트용 데이터 객체를 수락할 때, 사용자가 수정할 의도가 없는 민감한 필드를 포함해 일치하는 모든 필드를 무분별하게 업데이트할 수 있습니다. 공격자는 요청에 이러한 제한된 필드를 추가하여 권한 상승이나 중요 시스템 값 조작을 시도합니다.
대량 할당을 방지하려면 조직은 각 API가 업데이트할 수 있는 필드를 명시해야 합니다. 목록에 없는 필드는 차단하도록 구현하십시오. 일반 사용자 및 관리자 수준의 작업을 위한 API를 분리하십시오. 사용자 권한으로 각 필드 업데이트를 검증하십시오. 요청에 추가 필드를 포함하여 API를 테스트하거나 퍼징 도구를 구현하여 문제를 포착하십시오.
8. 크로스 오리진 리소스 공유(CORS)
크로스 오리진 리소스 공유(CORS) 규칙은 어떤 웹사이트가 조직의 API에 접근할 수 있는지 규제합니다. 간단히 말해, 취약한 CORS 구성은 모든 사이트가 해당 API를 호출할 수 있게 합니다. 개발 중에는 CORS가 모든 오리진을 허용하도록 설정됩니다. 그러나 조직들은 종종 이후에 이를 변경하는 것을 잊어버립니다.
CORS 문제를 해결하려면 조직의 API를 사용할 수 있는 웹사이트에 대한 구체적인 규칙을 구현해야 합니다. 운영 중인 API에 절대 "allow-all" 설정을 적용하지 마십시오. API 적용 방식에 대한 CORS 규칙을 반드시 확인하십시오.
9. 엔드포인트 보호 부족
API 엔드포인트 간 보안 통제가 일관되지 않을 경우 엔드포인트 보호가 불충분해집니다. 조직이 주요 엔드포인트에 강력한 보안 검사를 구현할 수 있지만, 깊게 중첩되거나 덜 가시적인 엔드포인트는 동일한 수준의 보호가 부족할 수 있습니다. 공격자는 보안 범위의 허점을 적극적으로 찾아내어 설정된 보안 제어를 우회하고 무단 액세스를 얻습니다.
조직은 가시성이나 네트워크 위치에 관계없이 모든 API 엔드포인트에 일관된 보안 제어를 구현해야 합니다. 인증, 권한 부여 및 입력 유효성 검사를 포함한 동일한 보안 표준을 모든 엔드포인트에 적용하십시오. 스테이징 및 테스트 환경과 같은 내부 네트워크의 엔드포인트를 포함하여 모든 엔드포인트를 정기적으로 스캔하여 균일한 보안 적용 범위를 보장해야 합니다.
10. 부적절한 오류 처리
오류가 적절하게 처리되지 않으면 공격자에게 데이터베이스 세부 정보, 서버 경로 또는 오류 덤프가 노출될 수 있습니다. 또한 오류로 인해 보안 검사가 작동하지 않을 수도 있습니다. 공격자는 오류 메시지를 악용하여 API에 대한 통찰력을 얻고 이를 더욱 악용합니다.
조직은 오류 처리를 개선하기 위해 시스템 세부 정보를 숨기는 표준 오류 메시지를 정의해야 합니다. 로그 파일과 사용자에게 동일한 오류 메시지를 전송하지 마십시오. 오류가 발생하더라도 보안 점검은 계속 작동해야 합니다. 공격 징후를 확인하기 위해 조직은 정기적으로 오류 로그를 점검해야 합니다.
11. 보안 설정 오류
API 설정이 admin123과 같은 기본값으로 설정된 경우 보안 설정 오류가 발생합니다. 대부분의 API는 테스트용 비밀번호, 개방된 포트 또는 기타 기본 보안 규칙으로 시작합니다. 논리적 문제를 해결하기 위해 조직은 때때로 보안 기능을 비활성화한 후 재활성화하는 것을 잊어버립니다. 반면 기본 설정은 권한을 필요 이상으로 허용하는 경향이 있으며, 시스템을 더 취약하게 만들 수 있는 불필요한 기능을 추가하기도 합니다.
조직은 보안 구성을 설정하고 모든 기본 비밀번호 및 접근 규칙을 변경해야 합니다. 사용자가 필요로 하지 않는 불필요한 API 기능은 비활성화하십시오. API 각 부분의 요구사항에 따라 보안 규칙을 구성하십시오. 문제를 식별하기 위해 API 구성을 정기적으로 검토하십시오. 잘못되거나 누락된 보안 구성을 탐지하는 보안 스캐닝 도구를 사용하십시오.
12. 안전하지 않은 종속성
API 개발 시 시간과 자원을 절약하기 위해 많은 제3자 코드 패키지가 사용됩니다. 이러한 패키지들은 종종 보안 문제가 있는 것으로 잘 알려져 있습니다. API가 내부적으로 안전하지 않은 패키지를 사용한다면, 공격자는 알려진 취약점을 악용하여 무단 접근을 얻을 수 있습니다.
의존성을 보호하기 위해 조직은 사용 전 모든 패키지의 보안 문제를 검증해야 합니다. 새로운 보안 조치가 발표되면 즉시 패키지 업데이트를 설치해야 합니다. 조직은 안전하지 않은 패키지에 대해 경고하는 오픈소스 의존성 스캐닝 도구(SCA 도구)를 사용해야 합니다.
13. 적절한 로깅 부족
부실한 API 로깅은 잠재적 위협을 포함할 수 있는 보안 사각지대를 생성하며, 사고 발생 시 조직의 대응 능력을 약화시킬 수 있습니다. 예를 들어, 접근 불가능한 위치에 로그를 저장하거나 로그의 무결성을 보호하지 못하는 등 부적절한 로그 관리는 공격자가 자신의 흔적을 지우거나 심지어 민감한 정보를 노출하는 데 도움이 될 수 있습니다.
강력한 로깅 관행을 개발하기 위해 조직은 요청 헤더 및 IP 주소, 사용된 인증 방법, 응답 코드 등과 같은 정보를 포함하여 모든 API 호출을 상세하게 기록해야 합니다. 이를 위해서는 로그를 중앙의 안전한 위치에 저장하고 각 로그에 대한 접근 권한을 통제해야 합니다.
14. 취약한 암호화
API가 취약한 암호화를 사용하는 경우 공격자가 민감한 데이터를 읽거나 수정할 가능성이 높습니다. 일부 조직은 취약점이 있는 구식 암호화 유형을 사용하는 API를 보유하고 있습니다. 다른 조직들은 사소한 데이터를 평문으로 전송하기도 합니다. 강력한 암호화도 잘못된 설정으로 인해 약화될 수 있습니다. 공격자들은 의심할 여지 없이 API 암호화의 취약점을 노려 민감한 데이터에 접근합니다.
API와 API가 처리하는 민감한 데이터를 보호하기 위해 조직은 AES와 같은 강력한 암호화를 사용해야 합니다. 개인 데이터를 전송하거나 저장할 때는 반드시 암호화하십시오. 새로운 보안 패치 출시 시 보안 가이드를 활용하여 암호화를 적절히 설정하고 암호화를 업데이트하십시오.
결론
우리는 디지털 세계에 연결되기 때문에 보안뿐만 아니라 일상생활에서도 API를 사용합니다. 해커들이 중요하고 숨겨진 취약점을 악용할 새로운 기회를 모색함에 따라 API 보안 위협과 위험이 증가하고 있습니다. API 취약점은 시스템을 탈취하거나 권한 상승을 유발하거나 서비스를 취약하게 만들 수 있습니다. 일부 기업은 API 공격으로 인해 사용자 인증, 온보딩 및 기타 프로세스에 영향을 받아 문을 닫기도 합니다. SentinelOne과 같은 도구는 API 보안 위험을 완화하고 통합을 원활하게 처리할 수 있습니다.
공격자가 발견하기 훨씬 전에 보안 문제를 식별할 수 있습니다. 또한 보안 도구에 의존하기만 하는 것이 아니라 최상의 API 보안 관행을 구현하는 것이 중요합니다. 이러한 영역에 주의를 기울임으로써 시간을 절약하고 사용자 데이터를 보호하며 고객 데이터를 위험에 빠뜨리지 않을 수 있습니다. 이는 심각한 중단이나 중단 없이 비즈니스 운영을 계속하는 데 도움이 될 것입니다.
"FAQs
API에 대한 세 가지 일반적인 위협은 접근 제어 결함, 취약한 인증, 인젝션 공격입니다. 액세스 제어 문제가 발생하면 사용자가 민감한 데이터를 볼 수 있습니다. 인증의 취약점은 공격자가 인증 메커니즘을 우회할 수 있게 하며, 인젝션 공격은 악성 페이로드를 전송하여 임의의 코드를 실행하고, 데이터베이스를 읽거나 업데이트하거나 삭제하는 등 다양한 피해를 입힙니다.
"API가 사용하는 인증 메커니즘이 어떤 식으로든 잘못 구성되었을 때 인증 결함이 발생합니다. 여기에는 만료되었어야 할 오래된 로그인 토큰 사용, 취약한 비밀번호, 응답 본문을 이용한 사용자 로그인(응답 조작 공격) 등이 포함됩니다. 이러한 문제로 인해 해커가 인증을 우회하고 민감한 정보에 접근할 수 있습니다.
"입력 검증은 잘 알려진 보안 모범 사례이지만 API 구현 시 매우 자주 무시됩니다. 입력 검증은 사용자가 API로 전송하는 모든 데이터를 분석하여 악의적인 데이터가 아닌지 확인합니다. 이러한 검사가 없으면 공격자는 SQLi, XSS 등과 같은 주입 공격을 수행하기 위해 정상적으로 보이는 요청에 숨겨진 악성 페이로드를 포함시킬 수 있습니다.
"API의 취약한 암호화는 공격자가 클라이언트와 서버 간에 전송되는 민감한 데이터를 가로채고 복호화할 수 있게 합니다. 이를 통해 공격자는 비밀번호, 결제 정보 및 기타 기밀 정보를 탈취할 수 있습니다.
"로깅과 모니터링은 비정상적인 패턴, 잠재적 침해, 의심스러운 활동을 실시간으로 추적하여 보안 위협을 탐지하고 대응하는 데 도움이 됩니다. 이는 사고 조사를 위한 감사 추적을 제공하며, 조직이 API가 어떻게 사용되거나 오용되는지 이해하는 데 기여합니다.
"보안 도구에는 API 스캐너, 웹 방화벽 및 위에서 언급한 SentinelOne과 같은 전문 플랫폼이 포함됩니다. 이러한 도구들은 함께 문제를 식별하고, 원치 않는 트래픽을 필터링하며, 다양한 보안 공격으로부터 API를 보호하는 데 도움을 줍니다.
"