코드 시리즈 - 비즈니스 논리로 보안 인프라를 정복하는 코더
글쎄, 이것은 (지금은) 것입니다. 우리는 코드 시리즈로 인프라의 끝에 도달했습니다. Docker, Ansible, Kubernetes, 테라폼 및 CloudFormation에서 보안 문제를 극복하는 데 재미를 보았으면 합니다. 하지만 이 사인오프 전에 비즈니스 논리 버그를 마스터할 수 있는 취약점이 하나 더 있습니다.
지금 실력을 테스트할 준비가 되었다고 생각하십니까? 최종 게임 챌린지를 시도해 보십시오.
몇 가지 에 아직도 불분명 한 경우, 읽기를 계속:
오늘날 우리가 집중하고자 하는 취약점은 비즈니스 논리 결함입니다. 이러한 규칙은 악의적인 사용자가 응용 프로그램을 악용하도록 선택할 경우 응용 프로그램을 다른 종류의 공격에 취약하게 만들 수 있는 비즈니스 논리 규칙을 제대로 구현하지 못할 때 발생할 수 있습니다. 각 응용 프로그램 내에서 구현된 목적과 기능에 따라 비즈니스 논리 결함으로 인해 권한 에스컬레이션, 부적절한 리소스 사용 또는 의도하지 않은 비즈니스 프로세스수를 수행할 수 있습니다.
많은 취약점과 달리 비즈니스 논리 규칙의 잘못된 구현은 놀라울 정도로 미묘할 수 있습니다. 응용 프로그램과 코드에 몰래 들어가지 않도록 특별한 경계가 필요합니다.
비즈니스 논리 결함의 몇 가지 예는 무엇입니까?
비즈니스 논리 결함을 유도하는 것이 얼마나 쉬운지 의 예로 Docker Compose 파일로 정의된 Docker 환경의 다음 예제를 고려하십시오. 컨테이너가 기능을 수행하도록 준비하려면 개발자는 다음 예제와 같이 Docker Compose 파일에 정의된 표준 리소스 정책을 사용할 수 있습니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
예약:
CPU: "0.5"
표면에는 잘 보이지만 컨테이너에 대한 이 리소스 정책이 리소스 사용을 제대로 제한하지는 않습니다. 공격자는 비즈니스 논리 결함을 활용하여 DoS(서비스 거부) 공격을 구현할 수 있습니다.
사용자가 너무 많은 리소스를 차지하는 것을 제한하기 위해 개발자는 각 컨테이너가 지원할 수 있는 것을 더 잘 정의하려고 할 수 있습니다. 따라서 새 코드에는 배치 제약 조건이 포함될 수 있습니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
예약:
CPU: "0.5"
배치:
제약 조건:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
언뜻 보기에 비즈니스 논리 결함을 해결하는 것처럼 보입니다. 그러나 새 배치 제약 조건은 Docker 컨테이너 서비스의 리소스 사용 제한에 영향을 주지 않습니다. 컨테이너를 예약하는 노드를 선택하는 데만 사용됩니다. 이 경우 DoS 공격은 여전히 가능합니다. 공격자는 먼저 Docker 컨테이너를 손상해야 하지만 그 이후에는 제한 없이 리소스를 배출할 수 있습니다.
당신이 볼 수 있듯이, 비즈니스 논리 결함에 대해 생각하고 그들을 제거하기 위해 프로그래밍은 까다로운 노력이 될 수 있습니다.
비즈니스 논리 결함 제거
비즈니스 논리 결함으로 핵심은 비즈니스 논리 결함이 존재한다는 것을 아는 것입니다. 새 코드가 작성되는 동안 환경에서 벗어나지 않도록 주의해야 합니다. 비즈니스 규칙 및 모범 사례는 설계, 구현 및 테스트를 포함한 응용 프로그램 개발 프로세스의 모든 단계에서 명확하게 정의되고 확인해야 합니다.
예를 들어 위의 예제와 같이 비즈니스 논리 결함이 DoS 공격을 사용하도록 설정하지 않도록 하려면 만드는 모든 Docker 컨테이너가 사용할 수 있는 리소스의 양을 제한하는 것이 좋습니다. 특히 제한 섹션은 Docker 컨테이너에서 사용할 수 있는 CPU 수와 메모리 양을 지정해야 합니다. 예를 들면 다음과 같은 것입니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
메모리: 100M
예약:
CPU: "0.5"
메모리: 50M
위의 예제와 같은 코드를 정책으로 사용하면 환경의 주요 비즈니스 논리 결함을 제거하고 DoS 공격을 방지할 수 있습니다. 공격자가 Docker 컨테이너 중 하나를 손상한 경우에도 이 작업이 작동합니다. 이 경우 공격자는 여전히 발판을 사용하여 리소스를 고갈시킬 수 없습니다.
위협 모델링은 다양한 공격이 일어나는 방식을 정의하고 비즈니스 논리 규칙을 사용하여 공격을 방지하고 제한하는 데 사용할 수 있도록 하여 유용할 수 있습니다. 규정 준수 규칙 및 알려진 악용 사례에 기반한 테스트는 균열을 통해 미끄러지는 비즈니스 논리 결함을 잡는 데 도움이 될 수 있습니다.
비즈니스 논리 결함은 응용 프로그램에 몰래 들어갈 수 있는 가장 미묘한 취약점 중 일부이지만 다른 더 높은 프로필 위험보다 덜 위험하지는 않습니다. 어떻게 발생할 수 있는지 알고 모범 사례를 사용하면 응용 프로그램 개발 중에 환경이 벗어나지 못하게 되어 악용하는 방법에 매우 익숙한 공격자가 악용할 수 있는 프로덕션 환경에 도달하지 못할 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 이 IaC 챌린지의 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
코드 시리즈 - 비즈니스 논리로 보안 인프라를 정복하는 코더
글쎄, 이것은 (지금은) 것입니다. 우리는 코드 시리즈로 인프라의 끝에 도달했습니다. Docker, Ansible, Kubernetes, 테라폼 및 CloudFormation에서 보안 문제를 극복하는 데 재미를 보았으면 합니다. 하지만 이 사인오프 전에 비즈니스 논리 버그를 마스터할 수 있는 취약점이 하나 더 있습니다.
지금 실력을 테스트할 준비가 되었다고 생각하십니까? 최종 게임 챌린지를 시도해 보십시오.
몇 가지 에 아직도 불분명 한 경우, 읽기를 계속:
오늘날 우리가 집중하고자 하는 취약점은 비즈니스 논리 결함입니다. 이러한 규칙은 악의적인 사용자가 응용 프로그램을 악용하도록 선택할 경우 응용 프로그램을 다른 종류의 공격에 취약하게 만들 수 있는 비즈니스 논리 규칙을 제대로 구현하지 못할 때 발생할 수 있습니다. 각 응용 프로그램 내에서 구현된 목적과 기능에 따라 비즈니스 논리 결함으로 인해 권한 에스컬레이션, 부적절한 리소스 사용 또는 의도하지 않은 비즈니스 프로세스수를 수행할 수 있습니다.
많은 취약점과 달리 비즈니스 논리 규칙의 잘못된 구현은 놀라울 정도로 미묘할 수 있습니다. 응용 프로그램과 코드에 몰래 들어가지 않도록 특별한 경계가 필요합니다.
비즈니스 논리 결함의 몇 가지 예는 무엇입니까?
비즈니스 논리 결함을 유도하는 것이 얼마나 쉬운지 의 예로 Docker Compose 파일로 정의된 Docker 환경의 다음 예제를 고려하십시오. 컨테이너가 기능을 수행하도록 준비하려면 개발자는 다음 예제와 같이 Docker Compose 파일에 정의된 표준 리소스 정책을 사용할 수 있습니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
예약:
CPU: "0.5"
표면에는 잘 보이지만 컨테이너에 대한 이 리소스 정책이 리소스 사용을 제대로 제한하지는 않습니다. 공격자는 비즈니스 논리 결함을 활용하여 DoS(서비스 거부) 공격을 구현할 수 있습니다.
사용자가 너무 많은 리소스를 차지하는 것을 제한하기 위해 개발자는 각 컨테이너가 지원할 수 있는 것을 더 잘 정의하려고 할 수 있습니다. 따라서 새 코드에는 배치 제약 조건이 포함될 수 있습니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
예약:
CPU: "0.5"
배치:
제약 조건:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
언뜻 보기에 비즈니스 논리 결함을 해결하는 것처럼 보입니다. 그러나 새 배치 제약 조건은 Docker 컨테이너 서비스의 리소스 사용 제한에 영향을 주지 않습니다. 컨테이너를 예약하는 노드를 선택하는 데만 사용됩니다. 이 경우 DoS 공격은 여전히 가능합니다. 공격자는 먼저 Docker 컨테이너를 손상해야 하지만 그 이후에는 제한 없이 리소스를 배출할 수 있습니다.
당신이 볼 수 있듯이, 비즈니스 논리 결함에 대해 생각하고 그들을 제거하기 위해 프로그래밍은 까다로운 노력이 될 수 있습니다.
비즈니스 논리 결함 제거
비즈니스 논리 결함으로 핵심은 비즈니스 논리 결함이 존재한다는 것을 아는 것입니다. 새 코드가 작성되는 동안 환경에서 벗어나지 않도록 주의해야 합니다. 비즈니스 규칙 및 모범 사례는 설계, 구현 및 테스트를 포함한 응용 프로그램 개발 프로세스의 모든 단계에서 명확하게 정의되고 확인해야 합니다.
예를 들어 위의 예제와 같이 비즈니스 논리 결함이 DoS 공격을 사용하도록 설정하지 않도록 하려면 만드는 모든 Docker 컨테이너가 사용할 수 있는 리소스의 양을 제한하는 것이 좋습니다. 특히 제한 섹션은 Docker 컨테이너에서 사용할 수 있는 CPU 수와 메모리 양을 지정해야 합니다. 예를 들면 다음과 같은 것입니다.
전개시키다:
리소스:
제한:
CPU: "0.5"
메모리: 100M
예약:
CPU: "0.5"
메모리: 50M
위의 예제와 같은 코드를 정책으로 사용하면 환경의 주요 비즈니스 논리 결함을 제거하고 DoS 공격을 방지할 수 있습니다. 공격자가 Docker 컨테이너 중 하나를 손상한 경우에도 이 작업이 작동합니다. 이 경우 공격자는 여전히 발판을 사용하여 리소스를 고갈시킬 수 없습니다.
위협 모델링은 다양한 공격이 일어나는 방식을 정의하고 비즈니스 논리 규칙을 사용하여 공격을 방지하고 제한하는 데 사용할 수 있도록 하여 유용할 수 있습니다. 규정 준수 규칙 및 알려진 악용 사례에 기반한 테스트는 균열을 통해 미끄러지는 비즈니스 논리 결함을 잡는 데 도움이 될 수 있습니다.
비즈니스 논리 결함은 응용 프로그램에 몰래 들어갈 수 있는 가장 미묘한 취약점 중 일부이지만 다른 더 높은 프로필 위험보다 덜 위험하지는 않습니다. 어떻게 발생할 수 있는지 알고 모범 사례를 사용하면 응용 프로그램 개발 중에 환경이 벗어나지 못하게 되어 악용하는 방법에 매우 익숙한 공격자가 악용할 수 있는 프로덕션 환경에 도달하지 못할 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 이 IaC 챌린지의 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
