요즘 사이버 보안에 대한 위협은 유비쿼터스이며 끊임없는 위협입니다. 프로그램이 배포된 후에도 따라잡으려고 노력하는 것이 거의 불가능해졌습니다. 그러나 DevSecOps의 이 시대에, 지속적인 납품 및 그 어느 때보다 많은 데이터 페이더트 시대에, 날카로운 조직은 개발자가 생산되기 전에 일반적인 취약점을 제거하는 데 도움이 되는 보안 인식 슈퍼스타로 의기양양하게 대할 수 있도록 돕고 있습니다. 웹 취약점과 자체 8개 인프라를 코드 버그로 해결했으며, 이제 는 다음 큰 소프트웨어 보안 과제에 익숙해졌습니다. 준비되었습니까?

이 다음 블로그 시리즈는 응용 프로그램 프로그래밍 인터페이스(API)와 관련된 최악의 보안 버그중 일부에 초점을 맞출 것입니다. 이러한 상태는 너무 나빠서 개방형 웹 응용 프로그램 보안프로젝트(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 환경 예제의 경우 개체에 액세스할 수 있는 사람을 엄격하게 정의하여 수정할 수 있습니다.

먼저 요청을 하는 사람을 식별하려면 확인 프로세스를 구현해야 합니다.

사용자 = userService.getUserByContext();

그런 다음 개체 ID가 존재하고 요청을 하는 사용자에게 속해야 합니다.

부울 순서는 존재 = getUserOrder ().stream()
.anyMatch(주문 -> (order.getId() == ID));

그리고 마지막으로, 우리는 객체를 삭제진행 :

order Repository.deleteById (id);

코드의 권한 부여 메서드가 조직의 사용자 정책 및 데이터 액세스 컨트롤과 일치하는지 확인해야 합니다. 코드가 완전히 안전한지 확인하는 방법으로 서로 다른 권한 수준이 있는 사용자가 작업을 수행하는 데 필요한 데이터에 액세스할 수 있는지 확인해야 하지만 제한해야 하는 모든 것을 보거나 변경하지 못하도록 해야 합니다. 이렇게 하면 실수로 간과된 개체 제어 취약점이 발견될 수 있습니다.

이러한 예제의 주요 테이크아웃은 먼저 사용자가 개체로 취할 수 있는 모든 작업을 정의한 다음 코드에 강력한 액세스 컨트롤을 직접 추가하는 것입니다. 마지막으로 상속된 부모 속성을 신뢰하지 말고 해당 작업을 수행하거나 다른 곳에서 해당 권한을 위임하지 마십시오. 대신 보호해야 하는 모든 개체 유형에 대해 코드에서 사용자 권한 및 작업을 명시적으로 정의합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.