Coders Conquer Security OWASP Top 10 API 시리즈 - 객체 수준 권한 부여 취약점(BOLA)

오늘날 사이버 보안 위협은 어디에나 존재하며 끊임없이 이어지고 있습니다. 상황이 너무 심각해져서 프로그램 배포 후 보안을 유지하는 것은 거의 불가능에 가까워졌습니다. 하지만 DevSecOps와 지속적 배포(Continuous Delivery), 그리고 그 어느 때보다 방대한 데이터가 쏟아지는 지금, 현명한 조직들은 개발자들이 보안을 고려하는 슈퍼스타로 성장하도록 지원하여 공통된 취약점을 프로덕션 환경에 배포되기 전에 제거하고 있습니다. 지금까지 웹 취약점과 인프라 코드(IaC) 상위 8대 버그를 다루었으니, 이제 다음으로 중요한 소프트웨어 보안 과제를 살펴볼 차례입니다. 준비되셨나요?

이번 블로그 시리즈에서는 애플리케이션 프로그래밍 인터페이스(API)와 관련된 가장 심각한 보안 버그들을 집중적으로 다룹니다. 이 버그들은 Open Web Application Security Project (OWASP)가 선정한 상위 API 취약점 목록에 포함될 정도로 위험합니다. 현대 컴퓨팅 인프라에서 API가 차지하는 비중을 고려할 때, 이러한 문제들은 애플리케이션과 프로그램에서 반드시 제거해야 할 치명적인 결함입니다.

코드를 통해 보안을 강화하는 것이 왜 필수적인지를 보여주는 완벽한 예시는 '객체 수준 권한 부여 취약점'에서 찾을 수 있습니다. 이는 프로그래머가 어떤 사용자가 객체와 데이터를 볼 수 있는지 명확하게 정의하지 않거나, 객체를 조회, 변경 또는 조작하기 위한 요청에 대해 검증 절차를 제공하지 않을 때 발생하며, 공격자가 API 엔드포인트를 통해 객체와 데이터를 무단으로 수정하거나 접근할 수 있게 만듭니다. API 엔드포인트는 API와 다른 시스템 간의 통신을 위한 접점(주로 URL)입니다. 앱 간의 연결성은 세계적으로 사랑받는 소프트웨어를 탄생시켰지만, 엔드포인트가 완벽하게 보호되지 않으면 여러 보안 위험에 노출될 수 있습니다.

또한 개발자가 부모 클래스의 속성을 상속받을 때, 코드 내의 중요한 검증 절차가 누락된다는 사실을 인지하지 못할 경우에도 발생할 수 있습니다. 일반적으로 사용자의 입력을 받아 데이터 소스에 접근하는 모든 기능에는 객체 수준 권한 부여 확인 절차가 포함되어야 합니다.

이미 이 내용에 익숙하며, 지금 바로 접근 제어 버그를 찾아 수정하고 제거할 수 있다고 생각하시나요? 게임화된 챌린지에 도전해 보세요:

결과는 어떠셨나요? 점수를 높이고 싶다면 계속 읽어보세요!

객체 수준 권한 부여 취약점의 예시에는 어떤 것들이 있을까요?

객체 수준 접근 제어 취약점은 공격자가 허용되지 않은 작업을 수행할 수 있게 합니다. 이는 관리자만 수행해야 할 민감한 데이터 조회나 레코드 삭제와 같은 작업일 수 있습니다. 보안이 매우 중요한 환경에서는 특정 권한이 있는 사용자 외에는 누구도 레코드를 볼 수 없도록 차단해야 할 수도 있습니다.
객체 수준 권한 부여를 정의할 때는 가능한 모든 작업을 고려해야 합니다. 예를 들어, Java Spring API에서 잠재적인 문제가 있는 엔드포인트는 다음과 같을 수 있습니다:

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

이 API 엔드포인트는 ID를 통해 주문을 삭제하지만, 해당 주문이 현재 로그인한 사용자의 것인지 확인하지 않습니다. 이는 공격자가 이 허점을 악용하여 다른 사용자의 주문을 삭제할 수 있는 기회를 제공합니다.

안전한 접근 제한을 올바르게 구현하려면 코드는 다음과 같이 작성되어야 합니다:

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

객체 수준 권한 부여 취약점 제거하기

접근 제어 코드가 지나치게 복잡할 필요는 없습니다. Java Spring API 환경 예시의 경우, 객체에 접근할 수 있는 사용자를 엄격하게 정의하는 것만으로도 문제를 해결할 수 있습니다.

먼저, 요청을 보낸 사용자가 누구인지 식별하기 위한 검증 절차를 구현해야 합니다:

User user = userService.getUserByContext();

다음으로, 객체 ID가 존재하며 요청을 보낸 사용자의 소유인지 확인해야 합니다.

boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));

마지막으로, 객체 삭제를 진행합니다.

orderRepository.deleteById(id);

코드 내 인증 방식이 조직의 사용자 정책 및 데이터 액세스 제어와 일치하는지 확인해야 합니다. 코드의 보안을 완벽하게 유지하려면, 사용자가 직무 수행에 필요한 데이터에는 접근할 수 있되 제한된 정보는 열람하거나 변경할 수 없도록 권한 수준별 검증 절차를 수행해야 합니다. 이를 통해 실수로 간과했던 객체 제어 취약점을 발견할 수 있습니다.

이 예제들의 핵심은 사용자가 객체에 대해 수행할 수 있는 모든 작업을 먼저 정의한 다음, 코드에 강력한 액세스 제어를 직접 추가하는 것입니다. 또한, 상속된 상위 속성에 의존하거나 해당 권한을 다른 곳에 위임하지 마십시오. 대신 보호해야 할 모든 객체 유형에 대해 사용자 권한과 작업을 코드에 명시적으로 정의해야 합니다.

이 취약점에 대한 더 자세한 정보와 조직 및 고객을 다양한 보안 위협으로부터 보호하는 방법은 Secure Code Warrior 블로그에서 확인하실 수 있습니다. 또한 데모를 체험하여 사이버 보안 기술을 지속적으로 연마하고 최신 상태로 유지해 보세요.