브라우저 기반 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. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 취약점을 선택하면 다음을 포함한 세부 정보를 확인할 수 있습니다:
   • Status: 취약점이 분류되었는지 또는 해결되었는지를 나타냅니다.
   • Description: 취약점의 원인, 잠재적 영향, 권장 해결 단계를 설명합니다.
   • Severity: 영향에 따라 여섯 단계로 분류됩니다. 심각도 수준 자세히 알아보기.
   • Scanner: 취약점을 탐지한 분석기를 식별합니다.
   • Method: 취약한 서버 상호작용 유형을 규정합니다.
   • URL: 취약점의 위치를 표시합니다.
   • Evidence: 해당 취약점의 존재를 입증하는 테스트 케이스를 설명합니다.
   • Identifiers: CWE 식별자처럼 취약점을 분류하는 데 사용된 참조 목록입니다.

보안 스캔 결과를 내려받을 수도 있습니다:

• 파이프라인의 Security 탭에서 Download results를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참고합니다.

최적화#

특정 애플리케이션이나 환경에 맞춰 DAST를 구성하는 방법은 구성 옵션을 참고합니다.

확산 적용#

단일 프로젝트에 DAST를 구성한 뒤에는 그 구성을 다른 프로젝트로 확장할 수 있습니다:

• 파이프라인이 매 실행마다 동일한 웹 서버에 배포하도록 구성돼 있다면 주의합니다. 서버가 업데이트되는 동안 DAST 스캔을 실행하면 부정확하고 비결정적인 결과가 나옵니다.

• 러너가 최신 버전의 분석기를 실행하도록 always 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가 발견 항목을 생성합니다.