블로그

코더는 보안 OWASP 상위 10 API 시리즈를 정복 - 깨진 개체 수준 권한 부여

마티아스 마두, Ph.
게시일: 2020년 9월 9일

요즘 사이버 보안에 대한 위협은 유비쿼터스이며 끊임없는 위협입니다. 프로그램이 배포된 후에도 따라잡으려고 노력하는 것이 거의 불가능해졌습니다. 그러나 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.



리소스 보기
리소스 보기

일반적으로 사용자의 입력을 사용하여 데이터 원본에 액세스하는 모든 기능에 대해 개체 수준 권한 부여 검사가 포함되어야 하며 그렇게 하지 않으면 큰 위험이 따릅니다.

더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약
공유하세요:
저자
마티아스 마두, Ph.
게시일: 2020년 9월 9일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하세요:

요즘 사이버 보안에 대한 위협은 유비쿼터스이며 끊임없는 위협입니다. 프로그램이 배포된 후에도 따라잡으려고 노력하는 것이 거의 불가능해졌습니다. 그러나 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.



리소스 보기
리소스 보기

아래 양식을 작성하여 보고서를 다운로드하세요.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

전송
양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.

요즘 사이버 보안에 대한 위협은 유비쿼터스이며 끊임없는 위협입니다. 프로그램이 배포된 후에도 따라잡으려고 노력하는 것이 거의 불가능해졌습니다. 그러나 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.



시작

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

보고서 보기데모 예약
리소스 보기
공유하세요:
더 알고 싶으신가요?

공유하세요:
저자
마티아스 마두, Ph.
게시일: 2020년 9월 9일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하세요:

요즘 사이버 보안에 대한 위협은 유비쿼터스이며 끊임없는 위협입니다. 프로그램이 배포된 후에도 따라잡으려고 노력하는 것이 거의 불가능해졌습니다. 그러나 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.



목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약다운로드
공유하세요:
리소스 허브

시작할 수 있는 리소스

더 많은 게시물
리소스 허브

시작할 수 있는 리소스

더 많은 게시물