코더는 보안 OWASP 상위 10 API 시리즈 정복 - 비활성화 된 보안 기능 / 디버그 기능 사용 / 부적절한 권한
이 목록의 대부분의 취약점은 API와 매우 관련이 있지만 비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 문제는 어디서나 공격할 수 있는 문제입니다. API에서 좀 더 널리 퍼질 가능성이 있지만 공격자는 종종 패치되지 않은 결함과 보호되지 않은 파일 또는 네트워크 의 어느 곳에서나 디렉토리를 찾으려고 시도합니다. 디버깅을 사용하도록 설정하거나 보안 기능을 사용하지 않도록 설정한 API를 통해 오면 악의적인 작업이 좀 더 쉬워집니다. 더 나쁜 것은 자동화된 도구가 보안 오구성을 감지하고 악용할 수 있으므로 환경에 있는 경우 악용될 가능성이 있으므로 이 취약점으로 인해 위험한 API 결함의 OWASP 목록이 발생하게 됩니다.
우리가 재미에 들어가기 전에,이 디버그 문제를 해결할 수 있는지 확인 :
비활성화된 보안 기능/디버그 기능을 활성화/부적절한 사용 권한 결함은 API에 어떻게 몰래 넣을 수 있습니까?
이 다차원 API 결함이 네트워크에 어떻게 추가되는지 확인하려면 해당 다차원 API 결함이 해당 구성 요소 부분으로 분해해야 합니다. 활성화된 디버그 기능 문제부터 시작해 보겠습니다. 디버깅은 개발자가 응용 프로그램이 제대로 수행되지 않거나 오류를 만들지 않는 이유를 파악하는 데 도움이 되는 유용한 도구입니다. 디버깅을 사용하도록 설정하면 오류 와 예외가 자세한 오류 페이지를 생성하므로 개발자가 무엇이 잘못되었는지 확인하고 문제를 해결할 수 있습니다. 응용 프로그램이 아직 개발 중인 동안 이 활성을 갖는 것은 완벽합니다.
그러나 대부분의 프레임워크에 디버깅이 활성화된 코드에서 프로덕션 환경에서 디버그 모드를 실행하는 것에 대한 경고가 있는 이유가 있습니다. 예를 들어:
# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = True
이 예제에서는 디버깅이 활성화되었습니다. 예외가 발생하면 장고 응용 프로그램은 자세한 오류 페이지를 생성합니다. 프로덕션 환경에서 이 작업을 수행하는 경우 적대범은 환경에 대한 메타데이터 정보를 포함하는 이러한 오류 페이지에 액세스할 수 있습니다. 대부분의 프레임워크는 기본적으로 디버깅을 해제했지만 긴 개발 프로세스 중에 활성화되면 다시 전환하는 것을 잊어버리기 쉽습니다. 그런 다음 응용 프로그램이 프로덕션 환경으로 이동하면 공격자에게 응용 프로그램 또는 전체 서버 또는 네트워크를 손상시키는 방법에 대한 많은 정보를 제공합니다.
디버그 모드를 사용하도록 설정하는 것은 대부분 독립 실행형 문제이지만 부적절한 사용 권한과 비활성화된 보안 기능은 취약점이 함께 작동하는 경우가 많습니다. 예를 들어 OWASP에서 제공하는 실제 시나리오에서 공격자는 검색 엔진을 사용하여 실수로 인터넷에 연결된 데이터베이스를 찾습니다. 인기 있는 데이터베이스 관리 시스템이 기본 구성을 사용하고 있었기 때문에 인증이 비활성화되었습니다. 따라서 부적절한 권한과 비활성화된 보안 기능을 결합하여 취약점을 제공함으로써 공격자는 PII, 개인 기본 설정 및 인증 데이터와 수백만 개의 레코드에 액세스할 수 있게 되었습니다.
비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 취약점 제거
이 취약점을 제거하는 두 갈래의 접근 방식을 만들어야 할 것입니다. 문제의 사용 가능한 디버그 부분을 제거하려면 개발 프로세스에 검사를 추가하여 API 또는 응용 프로그램을 프로덕션 환경으로 이동하기 전에 디버깅을 사용하지 않도록 하기만 하면 됩니다. 우리의 예에서, 그렇게 할 수있는 적절한 명령은 다음과 같습니다 .
# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = 거짓
이제 장고 응용 프로그램의 디버그 피쳐는 FALSE로 구성된 DEBUG 플래그로 비활성화됩니다. 오류에 대한 응답으로 오류 페이지가 생성되지 않습니다. 적대국이 여전히 오류 페이지에 액세스할 수 있는 경우 유용한 메타데이터가 포함되지 않으며 응용 프로그램에 위험을 초래하지 않습니다.
다양한 특정 취약점을 포괄할 수 있으므로 비활성화된 보안 기능 및 부적절한 권한 취약점제거가 훨씬 더 어렵습니다. 이를 막는 가장 좋은 방법은 표준적이고 반복 가능한 프로세스를 개발하여 잠긴 자산을 프로덕션 환경에 빠르고 쉽게 배포할 수 있도록 하는 것입니다.
그럼에도 불구하고 오케스트레이션 파일, API 구성 요소 및 Amazon S3 버킷 사용 권한과 같은 클라우드 서비스가 지속적으로 검토되고 업데이트되는 프로세스를 만들어야 합니다. 또한 이 검토는 조직이 항상 API 보안을 개선하고 있는지 확인하기 위해 시간이 지남에 따라 전체 환경의 보안 설정의 전반적인 효율성을 평가해야 합니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
코더는 보안 OWASP 상위 10 API 시리즈 정복 - 비활성화 된 보안 기능 / 디버그 기능 사용 / 부적절한 권한
이 목록의 대부분의 취약점은 API와 매우 관련이 있지만 비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 문제는 어디서나 공격할 수 있는 문제입니다. API에서 좀 더 널리 퍼질 가능성이 있지만 공격자는 종종 패치되지 않은 결함과 보호되지 않은 파일 또는 네트워크 의 어느 곳에서나 디렉토리를 찾으려고 시도합니다. 디버깅을 사용하도록 설정하거나 보안 기능을 사용하지 않도록 설정한 API를 통해 오면 악의적인 작업이 좀 더 쉬워집니다. 더 나쁜 것은 자동화된 도구가 보안 오구성을 감지하고 악용할 수 있으므로 환경에 있는 경우 악용될 가능성이 있으므로 이 취약점으로 인해 위험한 API 결함의 OWASP 목록이 발생하게 됩니다.
우리가 재미에 들어가기 전에,이 디버그 문제를 해결할 수 있는지 확인 :
비활성화된 보안 기능/디버그 기능을 활성화/부적절한 사용 권한 결함은 API에 어떻게 몰래 넣을 수 있습니까?
이 다차원 API 결함이 네트워크에 어떻게 추가되는지 확인하려면 해당 다차원 API 결함이 해당 구성 요소 부분으로 분해해야 합니다. 활성화된 디버그 기능 문제부터 시작해 보겠습니다. 디버깅은 개발자가 응용 프로그램이 제대로 수행되지 않거나 오류를 만들지 않는 이유를 파악하는 데 도움이 되는 유용한 도구입니다. 디버깅을 사용하도록 설정하면 오류 와 예외가 자세한 오류 페이지를 생성하므로 개발자가 무엇이 잘못되었는지 확인하고 문제를 해결할 수 있습니다. 응용 프로그램이 아직 개발 중인 동안 이 활성을 갖는 것은 완벽합니다.
그러나 대부분의 프레임워크에 디버깅이 활성화된 코드에서 프로덕션 환경에서 디버그 모드를 실행하는 것에 대한 경고가 있는 이유가 있습니다. 예를 들어:
# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = True
이 예제에서는 디버깅이 활성화되었습니다. 예외가 발생하면 장고 응용 프로그램은 자세한 오류 페이지를 생성합니다. 프로덕션 환경에서 이 작업을 수행하는 경우 적대범은 환경에 대한 메타데이터 정보를 포함하는 이러한 오류 페이지에 액세스할 수 있습니다. 대부분의 프레임워크는 기본적으로 디버깅을 해제했지만 긴 개발 프로세스 중에 활성화되면 다시 전환하는 것을 잊어버리기 쉽습니다. 그런 다음 응용 프로그램이 프로덕션 환경으로 이동하면 공격자에게 응용 프로그램 또는 전체 서버 또는 네트워크를 손상시키는 방법에 대한 많은 정보를 제공합니다.
디버그 모드를 사용하도록 설정하는 것은 대부분 독립 실행형 문제이지만 부적절한 사용 권한과 비활성화된 보안 기능은 취약점이 함께 작동하는 경우가 많습니다. 예를 들어 OWASP에서 제공하는 실제 시나리오에서 공격자는 검색 엔진을 사용하여 실수로 인터넷에 연결된 데이터베이스를 찾습니다. 인기 있는 데이터베이스 관리 시스템이 기본 구성을 사용하고 있었기 때문에 인증이 비활성화되었습니다. 따라서 부적절한 권한과 비활성화된 보안 기능을 결합하여 취약점을 제공함으로써 공격자는 PII, 개인 기본 설정 및 인증 데이터와 수백만 개의 레코드에 액세스할 수 있게 되었습니다.
비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 취약점 제거
이 취약점을 제거하는 두 갈래의 접근 방식을 만들어야 할 것입니다. 문제의 사용 가능한 디버그 부분을 제거하려면 개발 프로세스에 검사를 추가하여 API 또는 응용 프로그램을 프로덕션 환경으로 이동하기 전에 디버깅을 사용하지 않도록 하기만 하면 됩니다. 우리의 예에서, 그렇게 할 수있는 적절한 명령은 다음과 같습니다 .
# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = 거짓
이제 장고 응용 프로그램의 디버그 피쳐는 FALSE로 구성된 DEBUG 플래그로 비활성화됩니다. 오류에 대한 응답으로 오류 페이지가 생성되지 않습니다. 적대국이 여전히 오류 페이지에 액세스할 수 있는 경우 유용한 메타데이터가 포함되지 않으며 응용 프로그램에 위험을 초래하지 않습니다.
다양한 특정 취약점을 포괄할 수 있으므로 비활성화된 보안 기능 및 부적절한 권한 취약점제거가 훨씬 더 어렵습니다. 이를 막는 가장 좋은 방법은 표준적이고 반복 가능한 프로세스를 개발하여 잠긴 자산을 프로덕션 환경에 빠르고 쉽게 배포할 수 있도록 하는 것입니다.
그럼에도 불구하고 오케스트레이션 파일, API 구성 요소 및 Amazon S3 버킷 사용 권한과 같은 클라우드 서비스가 지속적으로 검토되고 업데이트되는 프로세스를 만들어야 합니다. 또한 이 검토는 조직이 항상 API 보안을 개선하고 있는지 확인하기 위해 시간이 지남에 따라 전체 환경의 보안 설정의 전반적인 효율성을 평가해야 합니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
