분석기 설정 사용자 정의

Scope 관리

Scope는 대상 애플리케이션을 크롤링할 때 DAST가 따르는 URL을 제어합니다. 적절하게 관리된 Scope는 스캔 실행 시간을 최소화하고 동시에 취약점을 확인하는 대상 애플리케이션만 확인합니다.

Scope의 종류

Scope에는 세 가지 유형이 있습니다.

in scope
out of scope
excluded from scope

In scope

DAST는 in-scope URL을 따르고 크롤링을 계속하기 위해 DOM을 검색합니다. 기록된 in-scope HTTP 메시지는 수동으로 취약점을 확인하고 전체 스캔을 실행할 때 공격을 수행하는 데 사용됩니다.

Out of scope

DAST는 이미지, 스타일 시트, 폰트, 스크립트 또는 AJAX 요청과 같은 문서가 아닌 콘텐츠 유형을 위해 out-of-scope URL을 따릅니다. 인증을 제외하고, DAST는 외부 웹 사이트로의 링크를 클릭할 때와 같이 완전한 페이지 로드를 위해 out-of-scope URL을 따르지 않습니다. 정보 누출을 검색하기 위한 수동 확인을 제외하고, out-of-scope URL에 대한 기록된 HTTP 메시지는 취약점을 확인하지 않습니다.

Excluded from scope

DAST는 excluded-from-scope URL을 따르지 않습니다. 정보 누출을 검색하기 위한 수동 확인을 제외하고, excluded-from-scope URL에 대한 기록된 HTTP 메시지는 취약점을 확인하지 않습니다.

인증 중에 Scope가 다르게 작동하는 방법

대상 애플리케이션 중 많은 것들이 SSO(단일로그인)를 위한 IAM(Identity Access Management) 공급자 사용과 같이 외부 웹 사이트에 의존하는 인증 프로세스가 있습니다. DAST가 이러한 공급자로 인증을 수행할 수 있도록 하기 위해, DAST는 인증 중에 완전한 페이지 로드를 위해 out-of-scope URL을 따릅니다. DAST는 excluded-from-scope URL을 따르지 않습니다.

DAST가 HTTP 요청을 차단하는 방법

Scope 규칙으로 인해 요청이 차단될 때, DAST는 브라우저에게 HTTP 요청을 평소처럼 수행하도록 지시합니다. 그런 다음 요청은 후속적으로 가로채여 BlockedByClient 이유로 거부됩니다. 이 접근 방식은 DAST가 HTTP 요청을 기록하면서도 이 요청이 대상 서버에 도달하지 않도록 보장합니다. 200.1과 같은 수동 확인은 외부 호스트로 전송된 정보를 확인하기 위해 이러한 기록된 요청을 사용합니다.

Scope 구성 방법

대상 애플리케이션의 호스트와 일치하는 URL은 기본적으로 in-scope로 간주됩니다. 다른 모든 호스트는 out-of-scope로 간주됩니다.

Scope는 다음 변수를 사용하여 구성됩니다.

DAST_SCOPE_ALLOW_HOSTS를 사용하여 in-scope 호스트를 추가합니다.
DAST_SCOPE_IGNORE_HOSTS를 사용하여 out-of-scope 호스트를 추가합니다.
DAST_SCOPE_EXCLUDE_HOSTS를 사용하여 excluded-from-scope 호스트를 추가합니다.
DAST_SCOPE_EXCLUDE_URLS를 사용하여 제외할 특정 URL을 설정합니다.

규칙:

호스트를 제외하는 것이 호스트를 무시하는 것보다 우선시됩니다. 호스트를 허용하는 것이 우선시됩니다.
호스트의 Scope를 구성하는 것은 해당 호스트의 하위 도메인에 대한 Scope를 설정하지 않습니다.
호스트의 Scope를 구성하는 것은 해당 호스트의 모든 포트에 대한 Scope를 설정하지 않습니다.

다음은 일반적인 구성입니다.

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_TARGET_URL: "https://my.site.com"                   # my.site.com URLs are considered in-scope by default
    DAST_SCOPE_ALLOW_HOSTS: "api.site.com:8443"       # include the API as part of the scan
    DAST_SCOPE_IGNORE_HOSTS: "analytics.site.com"      # explicitly disregard analytics from the scan
    DAST_SCOPE_EXCLUDE_HOSTS: "ads.site.com"           # don't visit any URLs on the ads subdomain
    DAST_SCOPE_EXCLUDE_URLS: "https://my.site.com/user/logout"  # don't visit this URL

취약점 탐지

취약점 탐지는 기본 Zed Attack Proxy (ZAP) 솔루션에서 점차적으로 브라우저 기반 분석기로 이관되고 있습니다. 이미 이관된 취약점 탐지에 대한 자세한 내용은 브라우저 기반 취약점 확인을 참조하십시오.

크롤러는 DAST/ZAP가 프록시 서버로 구성된 브라우저에서 대상 웹 사이트를 실행합니다. 이렇게 함으로써 브라우저에서 수행한 모든 요청과 응답이 DAST/ZAP에 의해 수동으로 스캔됨을 보장합니다. 전체 스캔을 실행할 때, DAST/ZAP에 의해 실행되는 활성 취약점 확인은 브라우저를 사용하지 않습니다. 취약점을 확인하는 방식의 차이로 인해 대상 웹 사이트의 특정 기능을 비활성화해야 할 수도 있습니다.

예를 들어, Anti-CSRF 토큰이 포함된 양식을 포함하는 대상 웹 사이트의 경우, 수동 스캔은 사용자가 페이지를 보는 것처럼 브라우저에서 페이지와 양식을 표시하므로 의도한대로 작동합니다. 그러나 전체 스캔에서 실행되는 활성 취약점 확인은 Anti-CSRF 토큰이 포함된 양식을 제출할 수 없을 수도 있습니다. 이러한 경우에는 전체 스캔 시 Anti-CSRF 토큰을 비활성화하는 것이 좋습니다.

스캔 시간 관리

기대하는 바는 브라우저 기반 크롤러를 실행하는 것이 표준 GitLab DAST 솔루션보다 많은 웹 애플리케이션에 대해 더 나은 커버리지를 제공한다는 것입니다. 이는 스캔 시간의 증가 비용을 지닐 수 있습니다.

커버리지와 스캔 시간 사이의 교환을 다음 조치로 관리할 수 있습니다:

변수 DAST_CRAWL_WORKER_COUNT를 사용하여 러너의 수직 스케일링을 하고 더 많은 브라우저 수를 사용합니다. 기본값은 사용 가능한 논리 CPU 수에 동적으로 설정됩니다.
변수 DAST_CRAWL_MAX_ACTIONS로 브라우저에 의해 실행되는 동작 수를 제한합니다. 기본값은 10,000입니다.
변수 DAST_CRAWL_MAX_DEPTH를 사용하여 브라우저 기반 크롤러가 커버리지를 확인하는 페이지깊이를 제한합니다. 크롤러는 너비 우선 검색 전략을 사용하므로 깊이가 작은 페이지가 먼저 크롤됩니다. 기본값은 10입니다.
변수 DAST_CRAWL_TIMEOUT로 대상 애플리케이션 크롤링에 소요되는 시간을 제한합니다. 기본값은 24h입니다. 크롤러 타임아웃 시 수동 및 활성 취약점 확인이 계속됩니다.
변수 DAST_CRAWL_GRAPH로 크롤 그래프를 작성합니다.
변수 DAST_SCOPE_EXCLUDE_URLS로 페이지 크롤을 방지합니다.
변수 DAST_SCOPE_EXCLUDE_ELEMENTS로 요소 선택을 방지합니다. 이 변수를 정의하는 것은 각 페이지 크롤링에 대한 추가 조사를 유발하므로 주의해서 사용해야 합니다.
대상 애플리케이션이 최소한이거나 빠른 렌더링을 가지고 있는 경우, 변수 DAST_PAGE_DOM_STABLE_WAIT을 더 작은 값으로 줄이는 것을 고려하십시오. 기본값은 500ms입니다.

타임아웃

네트워크 환경이 좋지 않거나 응용프로그램 부하가 많은 경우 기본 타임아웃은 응용프로그램에 적용되지 않을 수 있습니다.

브라우저 기반 스캔은 페이지 간의 이동이 원할하게 지속될 수 있도록 다양한 타임아웃을 조정할 수 있는 기능을 제공합니다. 이러한 값들은 기간 문자열을 사용하여 구성되며, 이를 통해 접두사를 사용하여 기간을 설정할 수 있습니다: 분의 경우 m, 초의 경우 s, 밀리초의 경우 ms를 사용합니다.

탐색 또는 새로운 페이지를 로딩하는 행위는 보통 JavaScript 또는 CSS 파일과 같은 여러 리소스를 로딩하기 때문에 일반적으로 가장 많은 시간이 소요됩니다. 이러한 리소스의 크기나 반환 속도에 따라 기본값인 DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT이 충분하지 않을 수 있습니다.

DAST_PAGE_DOM_READY_TIMEOUT 또는 DAST_PAGE_READY_AFTER_ACTION_TIMEOUT으로 설정할 수 있는 안정성 타임아웃 또한 구성할 수 있습니다. 안정성 타임아웃은 브라우저 기반 스캔이 페이지를 완전히 로딩한 것으로 간주하는 시점을 결정합니다. 브라우저 기반 스캔은 페이지가 로딩된 것으로 간주하며 다음 작업을 시도할 때:

DOMContentLoaded 이벤트가 발생했을 때
JavaScript 및 CSS와 같이 중요한 리퀘스트가 열려 있거나 미해결 상태가 아닐 때. 미디어 파일은 보통 중요하지 않게 간주됩니다.
브라우저가 탐색을 실행하거나 강제로 전환되었을 때나 작업을 실행한 후 DAST_PAGE_DOM_READY_TIMEOUT 또는 DAST_PAGE_READY_AFTER_ACTION_TIMEOUT 기간 이후에 새로운 Document Object Model (DOM) 수정 이벤트가 없을 때

위의 사건들이 발생하면 브라우저 기반 스캔은 페이지가 로딩되어 준비되었다고 간주하고 다음 작업을 시도합니다.

응용프로그램이 지연이 발생하거나 많은 탐색 실패가 발생하는 경우 이 예시와 같이 타임아웃 값을 조정하는 것을 고려해보세요:

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_TARGET_URL: "https://my.site.com"
    DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT: "45s"
    DAST_PAGE_READY_AFTER_ACTION_TIMEOUT: "15s"
    DAST_PAGE_DOM_READY_TIMEOUT: "15s"

참고: 이러한 값을 조정하면 각 브라우저가 각 활동을 완료하기 위해 기다리는 시간을 조정하므로 스캔 시간에 영향을 줄 수 있습니다.