11개의 API 취약점

개요

서평단 활동으로 “API 해킹의 모든 것”을 읽고 있다. 개발자로서 직, 간접적으로 접한 API 보안에 대하여 전반을 정리해주어서 도움이 된다.

여기서는 책을 읽는 중, 3장 “일반적인 API 취약점”을 정리해본다. 하나하나 읽고 고개 끄덕이는 것을 넘어서 내 것으로 만들기 위한 방법, 책 78p에서 이야기하는 “익숙해짐”을 위한 한 방법이다.

“이런 취약점에 익숙해지는 게 중요합니다. 그래야 취약점이 존재할 때 쉽게 알아채고, 공격할 때 악용하며, 이를 조직에 알려서 범죄자가 악용하기 전에 방비할 수 있습니다.”

알라딘 링크: http://aladin.kr/p/F40Nu

11개의 API 취약점

OWASP(Open Web Application Security Project) API 보안 상위 10위 목록중 9개와 정보 누출, 비즈니스 논리 결함 총 11개에 대해 간략히 정리해본다. 각각의 취약점들은 때로 겹치는 부분도 보인다.

1. Information Disclosure - 정보 누출

민감한 정보가 적절하지 않게 노출되는 것

권한 설정이 잘못 되었거나, 응답에서 과도한 정보를 담은 경우 등이 있겠다.

2. BOLA - Broken Object Level Authorization

접근 권한이 없는 데이터에 접근을 하는 경우이다. 예를 들어, A 사용자는 자신의 정보만 볼 수 있어야 하는 데, 같은 권한 수준을 가진 B 사용자의 정보까지 볼 수 있는 경우를 말한다.

3. Broken User Authentication - 사용자 인증 결함

로그인, API 토큰 생성, 처리 등등 인증 절차에서 발생하는 문제

중요한 비밀 정보가 GitHub에 올라가는 경우도 마찬가지이다.

4. Excessive Data Exposure - 데이터 과다 노출

API 호출에 대한 응답에 필요 이상의 과다한 응답을 하는 경우이다. 실제 개발에서도 이렇게 한 경우가 있었다. 나중에 또 다른 API 요구사항이 생길 것을 생각해서 미리 이것저것 다 응답하려 한 것이다.

• 자잘한 요구사항들에 대해 각각의 API를 만들어줘야 하는가? 라는 생각도 든다.
• GraphQL 이라면 정확히 요구하는 것을 명시할 수 있으니 대안이 될 수 있겠다.

5. Lack of Resource & Rate Limit - 리소스 부족과 속도 제한

API 요청을 할 수 있는 횟수의 제한이 필요하다.

• 제한이 없는 상황에서 너무 많은 요청이 오면 서비스 거부(Denial of Service, DoS)가 발생할 수 있다.
• 요금제별로 API 이용을 제한하는데 이를 우회하여 요금제 이상의 API 호출을 하게 된다면 회사의 수익에도 치명적이다.

(참고) 책에서는 속도 제한으로 번역하였는데 요청 제한 또는 호출 제한이 좀더 적절해 보인다.

6. BFLA - Broken Function Level Authorization

BOLA가 Access - 데이터 접근에 대한 문제라면 BFLA는 Action - 작업 수행에 대한 문제이다. 즉, 권한이 없는 작업을 수행하는 것이다.

7. Mass Assignment - 대량 할당

알려진 매개변수 이외에 숨겨진 매개변수가 있는 경우이다. 예를 들어, {”isAdmin”: true} 라는 매개변수만 넣어주면 관리자 권한을 가지게 되는 것이다.

8. Security Misconfiguration - 보안 설정 오류

보안과 관련한 설정을 잘못해둔 경우이다. 예를 들어, 전송 암호화 오류나 입력 유효성 검사(input sanitization) 등의 미비가 있겠다.

(참고) input sanitization은 입력 정제, 입력 정리 정도의 표현도 좋겠다.

9. Injection Flaw - 주입 결함

SQL Injection, NoSQL Injection, 시스템 명령 Injection등, 입력한 데이터를 백엔드가 코드로 취급하여 실행하는 결함이다.

10. Improper Assects Management - 부적절한 자원 관리

deprecated API, 개발중인 API를 방치하는 것을 말한다. 방치하여 두었기에 최신 보안 패치가 적용되지 않았거나, 개발중이기에 보안에 대해 충분히 고려하지 않은 것이다. 사용자가 이러한 API를 사용할 수 없도록 관리하여야 한다.

11. Business Logic Vulnerability - 비즈니스 로직 취약점

비즈니스 로직 자체의 취약점이기에 자동화된 보안도구로는 잡을 수 없다.

때로는 취약점이 노출되어 있음을 알면서도 사용자의 선의에만 의지하는 경우가 있는데 그래서는 안된다.

마무리

이렇게 나열해보니 선명하게 이해되는 부분도 있지만 중복되거나 막연하게 느껴지는 부분도 존재한다. 반복해서 접하다보면 명확해지리라.