게시일: 2024년 4월 8일
기고자: Annie Badman, Amber Forrest
다른 유형의 애플리케이션 보안(AppSec) 테스트와 비교했을 때 DAST는 아웃사이드-인(outside-in) 접근 방식이 뛰어납니다. 다른 도구는 보안 취약성을 평가하기 위해 소스 코드와 애플리케이션 내부 액세스가 필요한 반면, DAST는 외부에서 악의적인 행위자를 모방한 모의 공격을 사용하여 런타임 환경에서 애플리케이션을 테스트합니다. 이러한 이유로 DAST는 테스터가 내부 작업에 액세스하지 않거나 조사하지 않거나 심지어 알지 못하는 상태에서 시스템을 검사하는 테스트 방법인 아웃사이드-인 테스트 또는 블랙박스 테스트라고도 불립니다.
오늘날 개발자는 전체 코드베이스를 종합적으로 파악하지 못한 채 특정 코드 영역을 하루에 여러 번 업데이트하는 등 빠르게 작업하는 경우가 많습니다. 이들은 타사 및 오픈 소스 구성 요소에 크게 의존하며 보안 팀과 효과적으로 협업하는 데 어려움을 겪는 경우가 많습니다. 또한 대부분은 수많은 기능, 라이브러리, 종속성이 있는 점점 더 복잡해지고 있는 애플리케이션을 사용하면서 끊임없이 진화하는 사이버 보안 위협을 관리해야 합니다.
그 결과 보안 취약점의 표면적이 지속적으로 증가하여 보안 코드를 작성하고 데이터 침해로부터 민감한 정보를 보호하는 데 어려움을 겪게 됩니다. 개발자들은 작업 중에 생산성을 저하시키지 않으면서 잠재적 취약점을 테스트할 수 있는 방법이 필요합니다.
DAST는 보안 테스트 프로세스를 자동화하여 이를 가능하게 합니다. 실제 해커의 행동을 모방하여 외부에서 실행 중인 애플리케이션의 잠재적인 취약점을 발견하는 방식으로 작동합니다. 개발자는 DAST를 통해 코드를 테스트하고 앱이 출시되기 전에 전체 앱 보안에 미치는 영향을 확인할 수 있으며, 소프트웨어 구성 분석(SCA)과 같은 다른 테스트 방법으로는 종종 놓치기 쉬운 인증 오류 및 코드 취약점과 같은 보안 문제를 정확히 찾아낼 수 있습니다.
또한 최신 DAST(아래 참조) 도구는 DevOps 및 CI/CD 파이프라인에 원활하게 통합되어 애플리케이션 개발 워크플로 초기를 포함하여 개발의 모든 단계에 대한 인터페이스를 제공합니다.
빌드 및 배포 통합은 DevOps 팀이 보다 비용 효율적이고 시간이 덜 소요되는 문제 해결을 위해 소프트웨어 개발 라이프사이클(SDLC) 초기에 테스트를 수행하는 "시프트 레프트" 접근 방식의 일환으로 DevOps/DevSecOps 환경에서 DAST를 채택하는 이유 중 하나입니다. DAST 도구가 보완하는 다른 DevOps 원칙에는 자동화, 협업 및 지속적인 피드백의 우선순위 지정이 포함되어 있으며 이를 통해 개발자와 보안 팀은 보안을 손상시키지 않고 민첩성과 생산성을 유지할 수 있습니다.
DAST는 블랙박스 접근 방식을 취하기 때문에 악의적인 위협 행위자가 웹 애플리케이션을 침해하려고 할 때 취할 수 있는 행동을 에뮬레이션합니다.
일반적으로 DAST에는 다음과 같은 5단계가 포함됩니다.
첫 번째 단계로 DAST 스캐너는 다양한 HTTP 요청을 전송하여 런타임 애플리케이션과의 사용자 상호작용을 시뮬레이션합니다. 이 매핑은 API 정의 문서를 통해 API 테스트에 정의된 모든 페이지, 링크, 기능(단일 페이지 웹 앱의 경우) 및 진입점을 식별합니다.
요청이 전송되면 DAST 도구는 애플리케이션의 응답을 분석하기 시작하여 웹 애플리케이션 취약성을 나타낼 수 있는 이상 징후, 오류 메시지 및 예기치 않은 동작을 찾습니다. DAST 스캔이 잠재적인 취약성을 감지하면 나중에 참조할 수 있도록 해당 위치와 응답을 기록하여 필요한 경우 수동 테스트를 수행할 수 있습니다.
또한 DAST 도구는 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 크로스 사이트 요청 위조(CSRF)와 같은 일반적인 공격을 모방하여 위협 행위자가 악용할 수 있는 잘못된 구성, 데이터 노출, 인증 문제 등의 보안 취약점을 찾아내기 시작합니다.
분석 및 시뮬레이션된 공격에 따라 DAST 도구는 식별된 취약성, 심각도 및 잠재적 공격 시나리오를 요약한 보고서를 생성하여 개발자와 보안 팀을 안내합니다. DAST 솔루션은 보안 문제를 식별하는 데만 초점을 맞추고 모든 문제 해결은 개발 팀에 맡긴다는 점을 명심하세요.
DAST 도구는 때때로 오탐을 생성하여 무언가를 취약점으로 잘못 표시할 수 있습니다. 이런 일이 발생하면 종종 사람의 검증과 우선순위 지정이 필요합니다.
DAST 테스트 도구에는 공식적인 하위 유형이 없지만 보안 전문가들은 종종 최신 DAST 도구와 레거시 DAST 도구라는 두 가지 비공식 그룹으로 분류하며, 두 그룹의 주요 차이점은 자동화/통합과 취약성 검증입니다.
레거시 DAST 도구는 스캔 프로세스가 자동화되어 있지만 자동화 기능이 없는 경우가 많습니다. 일반적으로 요청을 보내고, 응답을 받고, 예비 평가를 하는 등 기본적인 테스트에 중점을 두며, 잠재적인 보안 문제 목록만 제공할 뿐 완전한 취약성 검증은 제공하지 않습니다.
최신 DAST 도구는 자동화 수준이 더 높으며 웹 애플리케이션의 취약성을 보다 철저히 검토합니다.
최신 DAST 솔루션은 SDLC에 원활하게 통합되고 백그라운드에서 투명하게 작동할 수 있습니다. 또한 자동화 서버는 최신 DAST 도구를 트리거하고 개발자의 이슈 트래커에 스캔 결과를 티켓으로 표시할 수 있습니다. 일부 최신 DAST 도구는 익스플로잇 증거를 제공하기 때문에 침투 테스터나 보안 전문가가 수동으로 확인하는 데 많은 시간이 소요되지 않습니다.
DAST는 종종 웹 애플리케이션 보안 테스트의 중요한 부분으로 생각됩니다. 다음과 같은 고유한 장점이 있습니다.
- 다재다능합니다. 사용자는 소프트웨어 개발 라이프사이클의 다양한 단계에서 DAST를 배포할 수 있으며, DAST는 실행 상태의 웹 애플리케이션과 수정 없이 이미 배포된 애플리케이션을 테스트할 수 있으므로 레거시 시스템을 더 쉽게 평가할 수 있습니다.
- 자동화되어 있습니다. DAST 도구는 DevOps 및 CI/CD 파이프라인에 쉽게 통합되므로 개발 프로세스 초기에 자동화된 보안 테스트를 실행하고 수정 비용을 크게 절감할 수 있습니다.
- 언어에 구애받지 않습니다. DAST는 외부에서 내부로 작동하기 때문에 애플리케이션에서 사용되는 프로그래밍 언어에 의존하지 않으며 다양한 프레임워크에서 작동할 수 있습니다. DAST는 공격자가 취약점을 찾는 방법을 에뮬레이션하여 웹 인터페이스와 API를 모두 효과적으로 테스트합니다.
- 오탐이 적습니다. DAST는 일반적으로 사용자 행동을 시뮬레이션할 때 SAST와 같은 다른 방법보다 오탐률과 부정률이 낮습니다.
- 현실적이며 반복 가능한 테스트를 할 수 있습니다. DAST는 실제 공격자의 행동을 에뮬레이션하기 때문에 악의적인 행위자가 악용할 수 있는 취약성을 식별하는 데 실용적인 솔루션입니다. 또한 DAST는 반복 가능한 테스트를 제공하기 때문에 애플리케이션이 발전함에 따라 지속적으로 취약성을 평가할 수 있습니다.
- 포괄적인 취약점을 발견합니다. DAST는 SQL 인젝션, XSS 및 구성 오류를 포함한 광범위한 취약점을 발견할 수 있습니다.
- 업계 표준에 부합합니다. 기업들은 종종 DAST를 사용하여 업계 표준을 준수하고 PCI 규정 준수와 같은 규정 보고를 지원합니다. 많은 기업이 애플리케이션 보안 위험에 대한 규정 준수 벤치마크로 OWASP Top 10 목록을 사용합니다.
이러한 많은 이점에도 불구하고 DAST에는 한계가 있을 수 있습니다. DAST는 실행 중인 애플리케이션의 보안 결함을 식별하는 데 능숙하지만 모든 취약점, 특히 특정 일련의 조치가 필요한 취약점을 찾아내지는 못할 수 있습니다. DAST를 정적 애플리케이션 보안 테스트(SAST - 아래 참조), 대화형 애플리케이션 보안 테스트(IAST), 소프트웨어 구성 분석(SCA), 수동 침투 테스트와 같은 다른 방법과 결합하면 DAST를 보완하고 보다 포괄적인 보안 프로그램을 제공할 수 있습니다.
DAST의 다른 제한 사항은 다음과 같습니다.
- 실행 코드에 중점을 둡니다. DAST는 대부분 이미 배포된 웹 애플리케이션의 일부(예: 이미 실행 가능한 코드)를 테스트하기 때문에 아직 개발 중인 섹션을 놓칠 수 있습니다.
- 인증과 관련하여 문제가 있을 수 있습니다. DAST는 비표준 인증 및 복잡한 비즈니스 로직에서는 효율성이 떨어질 수 있지만 전문 DAST 도구에는 이러한 상황에 대한 지침 모듈이 포함되어 있습니다.
- 운영적 영향입니다. 적절하게 조정하지 않으면 DAST 테스트가 정상적인 애플리케이션 작동에 영향을 미치고 샘플 데이터가 발생하거나 애플리케이션 속도가 느려질 수 있습니다. 따라서 많은 사람들이 라이브 프로덕션이 아닌 스테이징 또는 프로덕션 클론 환경에서 DAST를 실행합니다.
DAST 및 SAST(정적 애플리케이션 보안 테스트)는 웹 애플리케이션의 보안 취약성을 식별하는 데 사용되는 두 가지 테스트 방법입니다. 그러나 DAST는 프로덕션 환경에서 애플리케이션을 평가하고, 악의적인 사용자 공격을 모방하고, 보안 문제를 식별하는 반면, SAST는 소스 코드를 조사하여 웹 사이트 애플리케이션 내의 취약점을 찾습니다.
사이버 보안 전문가는 일반적으로 잠재적인 취약점을 완벽하게 파악하기 위해 보안 위험을 처리할 때 SAST와 DAST를 모두 사용할 것을 권장합니다. 예를 들어, 프로그램의 소스 코드를 검사할 때 SAST 도구는 SQL 인젝션, 버퍼 오버플로, XXE 공격 및 기타 OWASP Top 10 위험 등 DAST가 놓칠 수 있는 광범위한 보안 취약점을 발견할 수 있습니다.
또한 SAST 방법론을 사용하면 개발 중 조기 테스트를 장려하여 이후 단계에서 애플리케이션의 소스 코드에 보안 결함이 발생할 가능성을 줄여 개발 시간을 단축하고 전반적인 보안을 개선할 수 있습니다.