[RED팀] 지피지기면 백전불태, API보안 이해로 개인정보 철통방어!

앱 중심의 세상 속에서 혁신의 기본 요소는 API(Application Programming Interface)입니다. API는 클라우드, IoT, 모바일 등 다양한 환경에서 널리 활용되고 있는데요. 특히 API를 통해 전달되는 개인식별정보, 신용정보 등의 민감한 데이터의 유출은 심각한 결과를 초래할 수 있습니다. API 보안이 점차 중요해짐에 따라 국제 웹보안 분야의 대표적인 비영리단체인 OWASP(국제 웹 보안 표준기구, The Open Web Application Security Project)는 2019년에 API 보안 Top 10을 발표했습니다. 이 발표는 특성에 맞는 취약점의 관리와 완화 정책이 필요하다고 권고하고 있습니다.

API란 무엇인가?

API는 다른 애플리케이션과의 의사소통을 위한 사용자 인터페이스입니다. 즉 프론트엔드에서 백엔드에 정보를 요청할 때 사용 규칙을 제공하는 것입니다.

API는 접근 방식에 따라 다음과 같이 분류할 수 있습니다.

Open API: 백엔드에 서버를 만들어 놓고 외부에서 자유롭게 데이터를 가져다 쓸 수 있는 API입니다. 지도, AI 등 다양한 서비스가 존재합니다.
Internal API: 내부 개발자들의 편의를 위해 생성한 API입니다.

그리고 API의 대표적인 아키텍처 및 프로토콜은 다음과 같습니다.

REST(Representational State Transfer): HTTP 프로토콜 기반으로 설계됐으며, 메소드와 URI를 조합해, 예측 가능하고 일정한 정보 및 작업을 요청하고 받습니다.
SOAP(Simple Object Access Protocol): XML 프로토콜 기반으로 설계됐으며, SOAP의 WS-Security 표준은 XML 암호화, XML 서명 및 SAML 토큰을 사용하여 메시지 전송 시의 보안사항을 처리합니다.
GraphQL: 2013년에 페이스북이 REST의 한계를 극복하기 위해 만들었으며, 한 번의 요청으로 원하는 정보를 얻거나 수정합니다.

API 보안은 왜 중요한가?

앞서 설명한 것처럼 API 사용은 선택이 아닌 필수입니다. 66% 이상의 조직이 API를 공개해서 파트너와 외부 개발자가 소프트웨어 플랫폼과 앱 환경에 활용 중입니다<(출처: 2019 사이버공격을 통한 첨단산업비밀 유출 및 대응방안 보고서(국회정보위원회)>.

특히 API는 ▲광범위한 접근이 허용되고 ▲URI, 메소드, 헤더 및 파라미터들과 같은 웹 공격을 위한 요소들로 이뤄져 있으며 ▲구조와 정보를 알아보기 쉽다는 점에서 공격자들의 대상이 되기 쉽습니다.

OWASP이 선정한 API 보안 TOP 10

OWASP에서 제시하는 API 보안 10가지에 대해 자세히 살펴보겠습니다.

1.취약한 개체 수준 인가
개체는 사용자가 호출하려는 기능이나 데이터 대상을 말합니다. 사용자가 API 개체에 접근할 때 부여된 권한에 따라 유효성 체크가 이뤄지고 응답이 발생해야 합니다. ‘취약한 개체 수준 인가’는 해당 API 취약하다는 것을 의미합니다.

예를 들어, 다음과 같은 API 콜이 있다고 가정해보겠습니다. /shops/{shopName}/revenue_data.json 해당 API에 사용자 권한에 따른 개체별 권한 및 유효성 체크가 이루어지지 않으면, 공격자는 {shopName}에 예상되는 값을 대입해 수많은 가게의 판매 정보를 빼낼 수 있습니다.

2.취약한 사용자 인증
취약한 사용자 인증은 다음과 같습니다.

공격자가 가지고 있는 사용자 정보와 패스워드로 무작위로 대입해 로그인 시도를 해볼 수 있는 경우
CAPTCHA나 계정 잠금 없이 하나의 계정에 무작위 대입 공격 수행이 가능할 경우
취약한 비밀번호를 허용할 경우
URL에 인증 토큰 및 패스워드를 함께 전송할 경우
토큰의 진위 여부를 확인하지 않을 경우
서명되지 않거나 서명된 키를 추측 가능한 JWT 토큰을 사용하지 않으며, 사용 만기 기간을 규정하지 않았을 경우
평문 사용, 취약한 해시를 사용한 패스워드
취약한 암호 키를 사용할 경우

3.과도한 데이터 누출
과도한 데이터 누출이란 데이터의 민감도를 고려하지 않고 필요 이상의 데이터를 사용자의 요청에 따라 노출시키는 취약점입니다. 예를 들어, 사용자는 화면에서 이름, 부서, Email 주소만 확인하고 있지만, API 응답을 프록시 툴이나 로그를 통해 확인했을 때는 생일, 주소, 주민번호 등 민감한 정보를 함께 담아서 보낼 수 있는 경우를 말합니다. 이는 애플리케이션(Back-End)에서 응답 메시지에 대한 정합성 확인이 이뤄지지 않았음을 의미합니다.

4.리소스 부족 및 속도 제한
API 요청은 애플리케이션 서버에서 네트워크, CPU, 메모리 및 저장소의 자원을 사용합니다. 자원의 사용량은 사용자의 입력 값과 API 엔드포인트의 비즈니스 로직에 크게 영향을 받습니다. 또한 다중 API 호출은 자원의 사용량을 추가적으로 소요합니다. 따라서 아래의 설정이 누락되거나 적절히 반영되지 않았다면 해당 API는 취약하다고 볼 수 있습니다.

실행 시간제한
최대 할당 메모리
프로세스 수
파일 디스크립터 수
요청 페이로드 크기
클라이언트/자원별 요청의 수
하나의 요청/응답에 대해 하나의 페이지에 반환되는 레코드의 수

5.취약한 기능 수준 인가
그룹의 역할이 다르고 관리 및 일반 기능이 명확하지 않은 접근 권한 정책에 따른 권한 관리의 취약점을 말합니다. 다음과 같은 사용자 및 그룹별 권한은 취약한 것으로 판단할 수 있습니다.

일반 사용자가 관리자 API 엔드포인트에 접근할 수 있는 경우
일반 사용자가 데이터를 생성, 변경, 삭제 등의 부여되지 않은 권한의 행위를 수행할 수 있는 경우
그룹 X의 사용자가 그룹 Y가 접근할 수 있는 엔드포인트에 대해 간단한 URL 입력만으로 해당 행위를 수행할 수 있는 경우

6.대량 할당
API 개체는 많은 속성을 가지고 있습니다. 이들 가운데는 사용자들에 의해 직접 내용이 수정되기도 합니다(예: user.first_name, user.address 등). 이러한 API 개체의 속성 데이터들이 중요성이나 민감도에 관계없이 사용자가 입력한 값으로 변경됐을 때 취약하다고 볼 수 있습니다.

민감한 속성 예제

허가 관련 속성: 관리자 관련 속성 값 user.is_admin, user.is_vip
프로세스 관련 속성: 지불 확인 관련 속성 값 user.cash
내부 속성: 내부 애플리케이션 관련 속성 값 article.created_time

7.잘못된 보안 구성
API 엔드포인트의 보안설정이 안전하지 않은 구성이거나, 불완전한 임시 구성 상태를 유지했을 때 발생할 수 있는 취약점입니다.

백엔드 API 서버의 보안 설정이 미비하거나, 클라우드 서비스에서 허가 관련 설정이 부적절하게 된 경우
최신 보안 패치가 없거나 시스템이 오래된 경우
불필요한 기능이 활성화된 경우(예: 공격의 이용될 수 있는 HTTP 메소드)
TLS(전송 계층 보안)가 없는 경우
CORS (Cross-Origin Resource Sharing)* 정책이 누락되었거나 잘못 설정된 경우
에러 메시지에 스택 추적이 포함되거나 기타 중요한 정보가 노출된 경우
웹페이지상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조를 의미

8.인젝션
SQL, NoSQL 등에서 신뢰할 수 없는 데이터가 명령 또는 쿼리의 일부로 인터프리터에 전송돼 실행되는 취약점입니다.

클라이언트가 제공한 데이터가 API에 의해 검증, 필터링 또는 삭제되지 않을 경우
클라이언트가 제공한 데이터는 직접 사용되거나 SQL/NoSQL/LDAP 쿼리, OS 명령, XML 파서 및 ORM (Object Relational Mapping)/ODM (Object Document Mapper)에 직접 연결된 경우
외부 시스템(예: 통합 시스템)에서 오는 데이터가 API에 의해 검증, 필터링되지 않을 경우

9.부적절한 자산 관리
최신 API 버전을 사용함에 있어서, 기존 버전의 API를 사용 가능하거나 기존 버전의 API를 통해 데이터를 얻을 수 있음으로 발생하는 취약점입니다.

10.불충분한 로깅 및 모니터링
로깅 및 모니터링이 미흡해 공격자가 시스템을 지속적으로 공격해도 이를 발견하지 못할 수 있습니다. 추후에 사고 추적이 필요할 때 근거가 되는 데이터가 부족할 수 있는 취약점입니다.

API 취약점을 이용한 공격 수행 시 발견된 점

API 취약점을 이용해 AJAX API를 호출하는 웹사이트에서 공격을 수행했습니다. 이에 따라 POST 메소드로 바디 값에 action 파라미터로 개체를 호출하는 request가 있습니다. 그리고 해당 통신이 정상적으로 이뤄졌을 때 API에서 약속된 파라미터들을 응답으로 반환합니다. 이때 OWASP이 선정한 API 보안 TOP 10 중, 두 번째와 세 번째의 취약점이 발견됐습니다.

먼저, 과도한 데이터 누출 발생입니다. 위의 응답은 UI에서 이름, 전화번호, 주소만 띄워 주지만, 프록시에서 확인한 API 응답에는 Hash 암호화된 주민번호 등 민감정보 및 인증 관련 정보도 확인돼 과도한 데이터가 누출되는 취약점을 보여줍니다.

위의 그림과 같이 API 응답에서 획득한 데이터로 변수명과 변수 값 변조 시, 타인의 정보 접근이 가능합니다.

다음은 취약한 사용자 인증입니다. 다른 사용자의 개인 정보 및 인증 정보를 획득한 이후 추가 공격을 수행할 수 있었습니다.

API 보안의 정확한 이해로 보안 홀 예방을!

위의 공격에서 볼 수 있듯 API 보안 강화를 위해서는 인증과 권한 정책을 포괄적으로 구현해야 합니다. 또한 Token, Rate limiting, 암호화, API 게이트웨이 및 위협 모델링 등을 통해 API 보안성을 크게 강화할 수 있습니다.

Token: 토큰을 통해 권한이 있는 서비스 및 자원에 접근 및 활용할 수 있습니다.
Rate limiting 및 throttling: API콜의 속도를 제어하여DDoS 공격을 예방할 수 있습니다.
암호화: SSL/TLS 통신을 통해 보안성을 강화할 수 있습니다.
API Gateway: API 트래픽을 제어하고 API 사용의 사용에 대한 올바른 사용 여부 분석을 진행할 수 있습니다.
위협 모델링: 위협 모델링은 위험을 식별하고 평가하기 위한 구조화된 접근 방식입니다. 위협 모델링은 예방 조치로 가장 잘 사용되지만, 애플리케이션 취약성을 평가, 제거 및 예방하기 위해 지속적으로 수행되어야 합니다.

지금까지 OWASP API 보안 취약점 TOP 10과 API 보안 강화 방안에 대해 알아봤습니다. 기업들은 웹 애플리케이션에 대한 방어 및 취약점 진단을 수행하면서 많은 주의를 기울이고 있습니다. 실제로 기업들이 집중하는 웹 보안 측면은 API 보안에 대해 중복되거나, 자연스럽게 방어가 되는 경우도 있습니다. 하지만 API보안의 정확한 이해를 통해 미처 간과할 수 있는 보안의 홀(Hole)을 막아야 할 것입니다.

글ㅣ 박경진 선임
LG CNS RED팀 소속으로 웹 및 클라우드 취약점 진단에 대한 전문성을 높이고 있습니다. 보안관제 커리어를 시작으로 보안 아키텍처 구축과 개발 보안을 위한 데브섹옵스(DevSecOps) 구현 등 다양한 프로젝트 경험을 수행하고 있습니다.

블로그