브라우저 기반 DAST를 사용하면 웹 애플리케이션의 보안 취약점(CWE)을 식별할 수 있습니다. 웹 애플리케이션을 배포하면 배포 전에 감지할 수 없는 새로운 유형의 공격에 노출됩니다. 예를 들어, 애플리케이션 서버의 잘못된 구성이나 보안 제어에 대한 잘못된 가정은 소스 코드에서는 보이지 않을 수 있지만, 브라우저 기반 DAST로 감지할 수 있습니다.

동적 애플리케이션 보안 테스트(DAST)는 배포된 환경에서 이러한 취약점에 대해 애플리케이션을 검사합니다.

개요는 DAST - 고급 보안 테스트를 참조하세요.

DAST 브라우저 기반 분석기는 최신 웹 애플리케이션의 취약점을 스캔하기 위해 GitLab이 구축했습니다. 스캔은 브라우저에서 실행되어 단일 페이지 애플리케이션과 같이 JavaScript에 크게 의존하는 애플리케이션 테스트를 최적화합니다. DAST의 애플리케이션 스캔 방법에서 자세한 정보를 참조하세요.

CI/CD 파이프라인에 분석기를 추가하려면 분석기 활성화를 참조하세요.

시작하기#

DAST를 처음 사용하는 경우 이 가이드를 따라 첫 번째 스캔을 설정하세요.

필수 요건:

• Linux/amd64에서 docker 실행기를 갖춘 GitLab Runner.
• 배포된 대상 애플리케이션. 배포 옵션을 참조하세요.
• GitLab Runner와 대상 애플리케이션 간의 네트워크 연결.

DAST를 시작하려면:

1. 분석기를 활성화합니다. 파이프라인에서 스캐너를 실행하기 위해 DAST CI/CD job 만들기.
2. 인증을 구성합니다. 애플리케이션이 로그인을 요구하는 경우 DAST가 인증된 페이지를 스캔할 수 있도록 인증 설정.
3. 구성 문제를 해결합니다. 설정 중 문제가 발생하면 문제 해결 문서를 참조하세요.

다음 단계#

첫 번째 스캔 완료 후:

• 스캔 결과를 해석하는 방법을 알아보려면 결과 이해를 검토하세요.
• 스캔을 사용자 정의하려면 구성 옵션을 탐색하세요.
• DAST의 애플리케이션 스캔 방법에 대해 자세히 알아보세요.

결과 이해#

파이프라인에서 취약점을 검토할 수 있습니다:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 취약점을 선택하여 세부 정보를 봅니다. 세부 정보에는 다음이 포함됩니다:
   • 상태: 취약점이 분류되었거나 해결되었는지 나타냅니다.
   • 설명: 취약점의 원인, 잠재적 영향 및 권장 복구 단계를 설명합니다.
   • 심각도: 영향에 따라 6가지 수준으로 분류됩니다. 심각도 수준에 대해 자세히 알아보기.
   • 스캐너: 취약점을 감지한 분석기를 식별합니다.
   • 방법: 취약한 서버 상호작용 유형을 설정합니다.
   • URL: 취약점의 위치를 표시합니다.
   • 증거: 특정 취약점의 존재를 증명하는 테스트 케이스를 설명합니다.
   • 식별자: CWE 식별자와 같이 취약점을 분류하는 데 사용되는 참조 목록.

보안 스캔 결과를 다운로드할 수도 있습니다:

• 파이프라인의 Security 탭에서 결과 다운로드를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참조하세요.

최적화#

특정 애플리케이션 또는 환경에 대한 DAST 구성에 대한 정보는 구성 옵션을 참조하세요.

배포#

단일 프로젝트에 대해 DAST를 구성한 후 다른 프로젝트로 구성을 확장할 수 있습니다:

• 파이프라인이 각 실행 시 동일한 웹 서버에 배포하도록 구성된 경우 주의하세요. 서버가 업데이트되는 동안 DAST 스캔을 실행하면 부정확하고 비결정론적인 결과가 나타납니다.

• 러너가 최신 버전의 분석기를 실행하도록 항상 pull 정책을 사용하도록 구성합니다.

• 기본적으로 DAST는 파이프라인의 이전 job에서 정의한 모든 아티팩트를 다운로드합니다. DAST job이 테스트 중인 URL을 정의하기 위해 environment_url.txt 또는 이전 job에서 생성된 다른 파일에 의존하지 않는 경우 아티팩트를 다운로드해서는 안 됩니다. 아티팩트 다운로드를 피하려면 분석기 CI/CD job을 확장하여 의존성을 지정하지 않도록 합니다. 예를 들어, DAST 프록시 기반 분석기의 경우 .gitlab-ci.yml 파일에 다음을 추가합니다:

  dast:
    dependencies: []
  

DAST의 애플리케이션 스캔 방법#

스캔은 다음 단계를 수행합니다:

1. 구성된 경우 인증합니다.
2. 링크 따라가기, 버튼 클릭, 폼 작성과 같은 사용자 작업을 수행하여 애플리케이션의 표면 영역을 발견하기 위해 대상 애플리케이션을 크롤링합니다.
3. 크롤링 중에 발견된 HTTP 메시지 및 페이지에서 취약점을 검색하기 위해 패시브 스캔을 수행합니다.
4. 크롤링 단계 중에 기록된 HTTP 요청에 페이로드를 삽입하여 취약점을 검색하기 위해 액티브 스캔을 수행합니다.

애플리케이션 크롤링#

"탐색"은 버튼 클릭, 앵커 링크 클릭, 메뉴 항목 열기 또는 폼 작성과 같이 사용자가 페이지에서 수행할 수 있는 작업입니다. "탐색 경로"는 사용자가 애플리케이션을 탐색하는 방식을 나타내는 탐색 작업 시퀀스입니다. DAST는 페이지와 콘텐츠를 크롤링하고 탐색 경로를 식별하여 애플리케이션의 표면 영역을 발견합니다.

크롤링은 특별히 계측된 Chromium 브라우저에서 대상 애플리케이션 URL을 로드하는 탐색을 포함하는 탐색 경로로 초기화됩니다. DAST는 모든 탐색 경로가 크롤링될 때까지 탐색 경로를 크롤링합니다.

탐색 경로를 크롤링하기 위해 DAST는 브라우저 창을 열고 탐색 경로의 모든 탐색 작업을 수행하도록 지시합니다. 브라우저가 최종 작업의 결과 로딩을 마치면, DAST는 사용자가 취할 수 있는 작업에 대해 페이지를 검사하고, 발견된 각각에 대해 새 탐색을 만들어 탐색 경로에 추가하여 새 탐색 경로를 형성합니다. 예를 들어:

1. DAST가 탐색 경로 LoadURL[https://example.com]을 처리합니다.
2. DAST가 두 가지 사용자 작업 LeftClick[class=menu] 및 LeftClick[id=users]를 찾습니다.
3. DAST가 두 개의 새 탐색 경로 LoadURL[https://example.com] -> LeftClick[class=menu] 및 LoadURL[https://example.com] -> LeftClick[id=users]를 만듭니다.
4. 두 개의 새 탐색 경로에 대한 크롤링이 시작됩니다.

HTML 요소가 모든 페이지에서 보이는 메뉴와 같이 애플리케이션의 여러 곳에 존재하는 것은 일반적입니다. 중복 요소는 크롤러가 동일한 페이지를 다시 크롤링하거나 루프에 갇히게 할 수 있습니다. DAST는 이전에 크롤링한 새 탐색 작업을 버리기 위해 HTML 속성을 기반으로 한 요소 고유성 계산을 사용합니다.

패시브 스캔#

패시브 스캔은 스캔의 크롤링 단계 중에 발견된 페이지의 취약점을 확인합니다. 패시브 스캔은 데이터 삭제와 같은 파괴적인 작업을 포함하여 일반 사용자와 같은 방식으로 사이트와 상호작용하려 합니다. 그러나 패시브 스캔은 적대적인 동작을 시뮬레이션하지 않습니다. 패시브 스캔은 기본적으로 활성화됩니다.

검사는 취약점에 대해 HTTP 메시지, 쿠키, 스토리지 이벤트, 콘솔 이벤트 및 DOM을 검색합니다. 패시브 검사의 예시로는 노출된 신용카드, 노출된 시크릿 토큰, 누락된 콘텐츠 보안 정책, 신뢰할 수 없는 위치로의 리디렉션 검색 등이 있습니다.

개별 검사에 대한 자세한 내용은 검사를 참조하세요.

액티브 스캔#

액티브 스캔은 스캔의 크롤링 단계 중에 기록된 HTTP 요청에 공격 페이로드를 삽입하여 취약점을 확인합니다. 액티브 스캔은 적대적인 동작을 시뮬레이션하기 때문에 기본적으로 비활성화됩니다.

DAST는 각 기록된 HTTP 요청을 쿼리 값, 헤더 값, 쿠키 값, 폼 게시물 및 JSON 문자열 값과 같은 삽입 위치에 대해 분석합니다. 공격 페이로드가 삽입 위치에 삽입되어 새 요청을 형성합니다. DAST는 대상 애플리케이션에 요청을 보내고 HTTP 응답을 사용하여 공격 성공 여부를 결정합니다.

액티브 스캔은 두 가지 유형의 액티브 검사를 실행합니다:

• 매치 응답 공격은 응답 콘텐츠를 분석하여 공격 성공 여부를 결정합니다. 예를 들어, 공격이 시스템 암호 파일을 읽으려 한다면, 응답 본문에 암호 파일의 증거가 포함되어 있을 때 발견이 만들어집니다.
• 타이밍 공격은 응답 시간을 사용하여 공격 성공 여부를 결정합니다. 예를 들어, 공격이 대상 애플리케이션을 강제로 절전 모드로 만들려 한다면, 애플리케이션이 절전 시간보다 더 오래 응답하는 데 걸릴 때 발견이 만들어집니다. 타이밍 공격은 거짓 양성을 최소화하기 위해 다른 공격 페이로드로 여러 번 반복됩니다.

단순화된 타이밍 공격은 다음과 같이 작동합니다:

1. 크롤링 단계가 HTTP 요청 https://example.com?search=people을 기록합니다.
2. DAST가 URL을 분석하고 URL 파라미터 삽입 위치 https://example.com?search=[INJECT]를 찾습니다.
3. 액티브 검사가 Linux 호스트를 절전 모드로 만들려는 페이로드 sleep 10을 정의합니다.
4. DAST가 삽입된 페이로드 https://example.com?search=sleep%2010으로 대상 애플리케이션에 새 HTTP 요청을 보냅니다.
5. 대상 애플리케이션이 예를 들어 system(params[:search])처럼 유효성 검사 없이 쿼리 파라미터 값을 시스템 명령으로 실행하는 경우 취약합니다.
6. 응답 시간이 10초보다 오래 걸리면 DAST가 발견을 만듭니다.