분석기 설정 커스터마이즈

요약

범위는 대상 애플리케이션을 크롤링할 때 DAST가 따라가는 URL을 제어합니다. DAST는 범위 내 URL을 따라가며 크롤링을 계속하기 위해 수행할 후속 액션을 DOM에서 검색합니다. DAST는 이미지, 스타일시트, 폰트, 스크립트, AJAX 요청과 같이 문서가 아닌 콘텐츠 유형에 대해서는 범위 외 URL을 따라갑니다.

범위 관리#

범위는 대상 애플리케이션을 크롤링할 때 DAST가 따라가는 URL을 제어합니다. 범위를 적절히 관리하면 대상 애플리케이션만 취약점 검사 대상이 되도록 보장하면서 스캔 실행 시간을 최소화할 수 있습니다.

범위 유형#

범위 유형은 세 가지입니다:

범위 내
범위 외
범위에서 제외

범위 내#

DAST는 범위 내 URL을 따라가며 크롤링을 계속하기 위해 수행할 후속 액션을 DOM에서 검색합니다. 기록된 범위 내 HTTP 메시지는 취약점이 있는지 패시브 검사되며, 전체 스캔을 실행할 때 공격을 구성하는 데 사용됩니다.

범위 외#

DAST는 이미지, 스타일시트, 폰트, 스크립트, AJAX 요청과 같이 문서가 아닌 콘텐츠 유형에 대해서는 범위 외 URL을 따라갑니다. 인증을 제외하면, DAST는 외부 웹사이트로의 링크를 클릭하는 경우와 같은 전체 페이지 로드에 대해서는 범위 외 URL을 따라가지 않습니다. 정보 유출을 검색하는 패시브 검사를 제외하면, 범위 외 URL에 대해 기록된 HTTP 메시지는 취약점 검사를 하지 않습니다.

범위에서 제외#

DAST는 범위에서 제외된 URL을 따라가지 않습니다. 정보 유출을 검색하는 패시브 검사를 제외하면, 범위에서 제외된 URL에 대해 기록된 HTTP 메시지는 취약점 검사를 하지 않습니다.

인증 중에 범위가 다르게 작동하는 방식#

많은 대상 애플리케이션은 싱글 사인온(SSO)에 ID 액세스 관리 공급자를 사용하는 경우처럼 외부 웹사이트에 의존하는 인증 프로세스를 갖고 있습니다. DAST가 이러한 공급자로 인증할 수 있도록, DAST는 인증 중 전체 페이지 로드에 대해 범위 외 URL을 따라갑니다. DAST는 범위에서 제외된 URL은 따라가지 않습니다.

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

DAST는 범위 규칙 때문에 요청을 차단할 때 브라우저에 평소와 같이 HTTP 요청을 하도록 지시합니다. 이후 요청은 인터셉트되어 BlockedByClient 이유로 거부됩니다. 이 접근 방식을 통해 DAST는 HTTP 요청이 대상 서버에 도달하지 않도록 하면서 그 요청을 기록할 수 있습니다. 200.1과 같은 패시브 검사는 이렇게 기록된 요청을 사용하여 외부 호스트로 전송된 정보를 검증합니다.

범위 구성 방법#

기본적으로 대상 애플리케이션의 호스트와 일치하는 URL은 범위 내로 간주됩니다. 다른 모든 호스트는 범위 외로 간주됩니다.

범위는 다음 변수로 구성합니다:

DAST_SCOPE_ALLOW_HOSTS를 사용하여 범위 내 호스트를 추가합니다.
DAST_SCOPE_IGNORE_HOSTS를 사용하여 범위 외 호스트에 추가합니다.
DAST_SCOPE_EXCLUDE_HOSTS를 사용하여 범위에서 제외된 호스트에 추가합니다.
DAST_SCOPE_EXCLUDE_URLS를 사용하여 특정 URL을 범위에서 제외로 설정합니다.

규칙:

호스트 제외가 호스트 무시보다 우선하며, 호스트 무시는 호스트 허용보다 우선합니다.
호스트에 대한 범위 구성은 해당 호스트의 서브도메인에 대한 범위를 구성하지 않습니다.
호스트에 대한 범위 구성은 해당 호스트의 모든 포트에 대한 범위를 구성하지 않습니다.

다음은 일반적인 구성의 예입니다:

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

취약점 탐지#

DAST는 종합적인 브라우저 기반 취약점 검사를 통해 취약점을 탐지합니다. 이러한 검사는 스캔 중에 웹 애플리케이션의 보안 이슈를 식별합니다.

크롤러는 DAST를 프록시 서버로 구성한 상태에서 브라우저로 대상 웹사이트를 실행합니다. 이를 통해 브라우저가 만드는 모든 요청과 응답이 DAST에 의해 패시브 스캔됩니다. 전체 스캔을 실행할 때, DAST가 실행하는 액티브 취약점 검사는 브라우저를 사용하지 않습니다. 취약점을 검사하는 방식의 이러한 차이 때문에, 스캔이 의도한 대로 작동하도록 대상 웹사이트의 특정 기능을 비활성화해야 하는 문제가 발생할 수 있습니다.

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

스캔 시간 관리#

브라우저 기반 크롤러를 실행하면 표준 GitLab DAST 솔루션과 비교해 많은 웹 애플리케이션에서 더 나은 커버리지를 얻을 것으로 예상됩니다. 다만 스캔 시간이 늘어나는 비용이 수반될 수 있습니다.

다음 방법으로 커버리지와 스캔 시간 사이의 트레이드오프를 관리할 수 있습니다:

대상 애플리케이션에 템플릿 기반 페이지나 반복되는 콘텐츠가 있는 경우, DAST_CRAWL_GROUPED_URLS 변수로 URL을 그룹화할 수 있습니다.
러너를 수직 확장하고 변수 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입니다.

타임아웃#

네트워크 상태가 좋지 않거나 애플리케이션 부하가 심한 경우, 기본 타임아웃이 애플리케이션에 적합하지 않을 수 있습니다.

브라우저 기반 스캔은 한 페이지에서 다음 페이지로 전환할 때 원활하게 계속되도록 다양한 타임아웃을 조정하는 기능을 제공합니다. 이 값들은 Duration string으로 구성하며, 분은 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 기간 이후에 새로운 DOM(Document Object Model) 수정 이벤트가 없습니다.

이러한 이벤트가 발생한 후, 브라우저 기반 스캔은 페이지가 로드되어 준비된 것으로 간주하고 다음 액션을 시도합니다.

애플리케이션에 지연이 발생하거나 내비게이션 실패가 많이 반환되는 경우, 다음 예시와 같이 타임아웃 값을 조정하는 것을 고려합니다:

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"

Note

이 값들을 조정하면 각 브라우저가 여러 활동이 완료될 때까지 기다리는 시간이 조정되므로 스캔 시간에 영향을 줄 수 있습니다.

페이지 준비 타임아웃#

페이지 준비는 페이지가 완전히 로드되고 DOM이 안정화되어 인터랙티브 요소를 사용할 수 있는 상태를 말합니다. 올바른 페이지 준비 감지는 다음에 매우 중요합니다:

스캔 정확성: 페이지가 완전히 로드되기 전에 분석하면 콘텐츠를 놓치거나 거짓 음성이 발생할 수 있습니다.
크롤 효율성: 너무 오래 기다리면 스캔 시간이 낭비되고, 충분히 기다리지 않으면 동적 콘텐츠를 놓칩니다.
현대 웹 애플리케이션 지원: 싱글 페이지 애플리케이션, AJAX가 많은 사이트, 프로그레시브 로딩 패턴은 정교한 준비 감지가 필요합니다.

선택적으로 구성할 수 있는 타임아웃 시퀀스를 사용하여 DAST 스캐너는 페이지의 각 부분이 완전히 로드된 시점을 감지할 수 있습니다.

타임아웃 변수#

다음 CI/CD 변수를 사용하여 DAST 페이지 준비 타임아웃을 커스터마이즈합니다. 전체 목록은 사용 가능한 CI/CD 변수를 참고합니다.

타임아웃 변수	기본값	설명
`DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT`	`15s`	브라우저가 한 페이지에서 다른 페이지로 이동할 때까지 기다리는 최대 시간. 전체 페이지 로드의 문서 로드 단계에서 사용됩니다.
`DAST_PAGE_READY_AFTER_ACTION_TIMEOUT`	`7s`	브라우저가 페이지를 로드되어 분석할 준비가 된 것으로 간주할 때까지 기다리는 최대 시간. 전체 페이지 로드를 트리거하지 않는 페이지 내 액션에 대해 `DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT`의 대안으로 사용됩니다.
`DAST_PAGE_DOM_STABLE_WAIT`	`500ms`	페이지가 안정적인지 확인하기 전에 DOM 업데이트를 기다리는 시간을 정의합니다. 클라이언트 측 렌더링 단계 시작 시 사용됩니다.
`DAST_PAGE_DOM_READY_TIMEOUT`	`6s`	내비게이션이 완료된 후 브라우저가 페이지를 로드되어 분석할 준비가 된 것으로 간주할 때까지 기다리는 최대 시간. 백그라운드 데이터 가져오기와 DOM 렌더링 대기를 제어합니다.
`DAST_PAGE_IS_LOADING_ELEMENT`	없음	페이지에서 더 이상 표시되지 않을 때 분석기에 페이지 로딩이 완료되어 스캔을 계속할 수 있음을 알리는 선택자. 클라이언트 측 렌더링 프로세스의 끝을 나타냅니다.

페이지 로딩 워크플로#

현대 웹 애플리케이션은 여러 단계로 로드됩니다. DAST 스캐너는 이 과정의 각 단계마다 특정 타임아웃을 갖습니다:

문서 로딩: 브라우저가 기본 페이지 구조를 가져와 처리합니다.
1. 서버에서 HTML 콘텐츠를 가져옵니다.
2. 참조된 CSS 및 JavaScript 파일을 로드합니다.
3. 콘텐츠를 파싱하고 초기 페이지를 렌더링합니다.
4. 표준 "document ready" 이벤트를 트리거합니다.
이 단계에서는 문서 로딩의 최대 대기 시간을 설정하는 DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT(전체 페이지 로드의 경우) 또는 DAST_PAGE_READY_AFTER_ACTION_TIMEOUT(페이지 내 액션의 경우)을 사용합니다.
클라이언트 측 렌더링: 초기 로딩 이후, 많은 싱글 페이지 애플리케이션은 다음을 수행합니다:
- 초기 JavaScript 실행을 수행합니다(DAST_PAGE_DOM_STABLE_WAIT).
- AJAX 또는 다른 API 호출로 백그라운드 데이터를 가져옵니다.
- DOM을 렌더링하고 가져온 데이터를 기반으로 업데이트를 수행합니다(DAST_PAGE_DOM_READY_TIMEOUT).
- 페이지 로딩 표시기를 표시합니다(DAST_PAGE_IS_LOADING_ELEMENT).
스캐너는 이러한 활동을 모니터링하여 페이지가 인터랙션 준비가 된 시점을 판단합니다.

다음 차트는 페이지를 크롤링할 때 사용되는 타임아웃 순서를 보여줍니다:

Mermaid 다이어그램 (27줄)

소스 코드 보기

%%{init: {
  "gantt": {
    "leftPadding": 250,
    "sectionFontSize": 15,
    "topPadding": 40,
    "fontFamily": "GitLab Sans"
  }
}}%%
gantt
    accTitle: DAST timeout sequence during page load
    accDescr: Timeline showing when DAST timeout configurations apply during the two phases of page loading.
dateFormat YYYY-MM-DD
axisFormat  %d
section     Document load
DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT :done, nav1, 2024-01-01, 6d
Fetch HTML :active, nav1, 2024-01-01, 3d
Fetch CSS&amp;JS :active, nav1, 2024-01-04, 3d
DocumentReady :milestone, nav1, 2024-01-07, 0d

section     Load Data / Client-side render
DAST_PAGE_DOM_STABLE_WAIT :done, dom1, 2024-01-07, 3d
Initial JS Execution :active, dom1, 2024-01-07, 3d
DAST_PAGE_DOM_READY_TIMEOUT :done, ready1, 2024-01-10, 4d
Fetch Data :active, dom1, 2024-01-10, 2d
Render DOM :active, dom1, 2024-01-10, 2d
DAST_PAGE_IS_LOADING_ELEMENT :milestone, load1, 2024-01-14, 0d</code></pre></details></div>

그룹화된 URL#
웹사이트에 대해 DAST 스캐너를 실행하면 일반적인 스캔이 완료되기까지 몇 시간이 걸릴 수 있습니다.
이 지연은 웹사이트에 동일한 템플릿을 사용하면서 정보만 다른 유사한 페이지가 수천 개 포함되어 있을 때
발생합니다. DAST는 각 페이지를 별개로 취급해 개별 분석하므로, 이러한 유사한 페이지를 크롤링하는 데
스캔 시간의 대부분을 소비합니다.
예를 들어:

수천 개의 제품 페이지가 있는 이커머스 사이트(/products/item-123, /products/item-456)
사용자 프로필이 있는 소셜 플랫폼(/users/john, /users/jane)
분류된 기사가 있는 콘텐츠 관리 시스템(/blog/category/tech, /blog/category/news)
페이지가 나뉜 결과가 있는 검색 인터페이스(/search?q=term&page=1, /search?q=term&page=2)

모든 URL을 고유한 것으로 취급하는 대신, 그룹화된 URL을 사용하면 유사한 URL을 함께 묶는 와일드카드 패턴을
정의할 수 있습니다. DAST가 이러한 패턴과 일치하는 URL을 만나면, 보안 커버리지를 유지하면서 스캔 시간을 줄이기 위해
각 그룹에서 대표 URL 하나만 분석합니다.
예를 들어, 모든 제품 상세 페이지가 동일한 구조와 보안 모델을 따른다면 DAST는 그중 하나만 철저히
테스트하면 됩니다.
그룹화된 URL 작동 방식#
그룹화된 URL 패턴을 구성하면 DAST의 크롤러가 크롤을 최적화합니다:

패턴 매칭: 크롤러가 새 URL을 발견하면 정의한 패턴과 각각 대조합니다.
스마트 그룹화: 패턴과 일치하는 URL은 함께 그룹화되며, 처음 발견된 URL만 완전히
분석됩니다.
내비게이션 건너뜀: 동일한 패턴과 일치하는 후속 URL은 전체 크롤링에서 제외되지만 보고를 위해 여전히
기록됩니다.
보안 커버리지: 대표 URL에서 수행한 보안 분석이 그룹 전체에 적용됩니다.

Warning
그룹화된 URL 구성 때문에 건너뛴 URL이 크롤 그래프에서 visited 또는 failed로 표시될 수 있습니다. 이는 알려진 이슈입니다. 자세한 내용은
이슈 577252를 참고합니다.

구성 예시 가이드#
다음 예시는 가상의 이커머스 웹사이트를 사용합니다. 이 사이트에는 쿼리 파라미터로 다양한 필터를 받는 제품 목록 페이지와,
URL의 하위 경로에 제품 식별자가 들어가는 제품 상세 페이지가 있습니다.
애플리케이션의 URL 패턴 분석
그룹화된 URL을 구성하기 전에 애플리케이션의 URL 구조를 파악합니다:

사이트맵 또는 애플리케이션 경로를 검토합니다.
이전 스캔의 DAST 로그를 살펴 반복되는 패턴을 파악합니다.
URL을 기능적 목적(제품 페이지, 사용자 프로필, 검색 결과)별로 분류합니다.
동일한 페이지 구조를 공유하는 템플릿 기반 페이지를 파악합니다.

이 예시에서 이커머스 사이트를 스캔하면 CI 아티팩트에 있는 로그 파일에 다음 URL이 기록됩니다:
INF REPT  visited 8 URLs
INF REPT  URL visited: (DOC www.your-site.com/products?category=vegetables&sort=price) GET www.your-site.com/products?category=vegetables&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=fruits&sort=price) GET www.your-site.com/products?category=fruits&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=frozen&sort=price) GET www.your-site.com/products?category=frozen&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=frozen&sort=price) GET www.your-site.com/products?category=frozen&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products/029039-apple-93000/details) GET www.your-site.com/products/029039-apple-93000/details
INF REPT  URL visited: (DOC www.your-site.com/products/99345-orange-33322/details) GET www.your-site.com/products/99345-orange/details
INF REPT  URL visited: (DOC www.your-site.com/products/90845-orange-33992/details) GET www.your-site.com/products/90845-orange/details
INF REPT  URL visited: (DOC www.your-site.com/products/100232-bananas-2677/details) GET www.your-site.com/products/100232-bananas-2677/details

처음 네 URL은 category 및 sort 필터가 서로 다른 제품 목록 페이지입니다.
마지막 네 URL은 고유한 제품 식별자를 가진 개별 제품 상세 페이지입니다.
제품 상세 페이지 중 두 개는 식별자에 orange가 포함되어 있습니다.
이 두 종류의 페이지는 동일한 기본 템플릿과 보안 특성을 공유할 가능성이 높습니다.
그룹화된 URL로 최적화하지 않으면 DAST는 여덟 개 페이지를 모두 개별적으로 크롤링하고 테스트합니다.
와일드카드 패턴 설계
패턴을 만들 때는 다음 규칙을 따릅니다:

패턴 인식을 위해 * 와일드카드를 하나 이상 포함합니다. *는 URL에서 0개 이상의 문자와 일치합니다.
URL은 URL의 특정 부분이 아니라 문자 단위로 매칭됩니다. *는 URL의 하위 경로 두 개 이상과도 일치할 수 있습니다.
크롤 과정에서 URL의 어느 문자가 변하는지 찾습니다. 관련 없는 페이지까지 과도하게 묶이지 않도록 구체적으로 지정합니다.
패턴 순서를 고려합니다. 페이지가 여러 패턴과 일치하면 먼저 지정한 패턴이 사용됩니다.

이커머스 웹사이트의 패턴을 다음과 같이 구성합니다:

제품 카테고리 목록 그룹 패턴: 처음 네 URL은 www.your-site.com/products?category=*&sort=price 패턴으로
논리적으로 묶을 수 있습니다. 이 패턴은 카테고리 필터를 사용하면서 sort 필터로 price를 지정하는 모든
페이지와 일치합니다.
제품 상세 그룹 패턴: 마지막 네 URL은 www.your-site.com/products/*/details 패턴으로 논리적으로 묶을
수 있습니다. 이 패턴은 제품 식별자와 무관하게 모든 제품 상세 페이지와
일치합니다.

제품 상세 그룹 패턴을 두 그룹으로 더 나눌 수도 있습니다:

오렌지 제품 상세 그룹 패턴: www.your-site.com/products/*orange*/details 패턴은 오렌지에 해당하는 두 URL과 일치합니다.
일반 제품 상세 그룹 패턴: www.your-site.com/products/*/details 패턴은 그 외 모든 제품과 일치합니다.

한 페이지가 두 개 이상의 URL 패턴과 일치할 수 있습니다. 매칭하고자 하는 순서대로 패턴을 지정합니다. 예를 들어
www.your-site.com/products/4782-orange-777/details는 두 패턴 모두와 일치하지만, 이 페이지는 오렌지 제품 상세 페이지입니다.
오렌지 제품 상세 그룹 패턴과 일치하도록 하려면, 구성에서 일반 제품 상세 그룹 패턴보다 앞에 오렌지 제품 상세
패턴을 지정합니다.
DAST_CRAWL_GROUPED_URLS 변수 구성
.gitlab-ci.yml 파일에 다음 구성을 추가합니다:
include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/products?category=*&sort=price,https://your-site.com/products/*orange*/details,https://your-site.com/products/*/details"

모니터링 및 검증
그룹화된 URL을 구현한 후:

크롤 그래프(활성화한 경우)를 확인하여 그룹화 동작을 검증합니다. 크롤 그래프의 분기가 줄어들어야 합니다.
스캔 로그를 검토하여 예상한 URL 차단을 확인합니다. 방문된 URL이 줄어들어야 합니다.
보안 커버리지가 손상되지 않았는지 검증합니다. 그룹당 한 페이지만 취약점 스캔을 하므로 발견 건수가 줄어들 수 있습니다.
스캔 기간의 성능 향상을 측정합니다. 스캔이 끝나는 데 걸리는 시간이 줄어들어야 합니다.

고급 구성 예시#
다음 예시는 일반적인 웹 애플리케이션 시나리오에 적용할 수 있는 고급 패턴을 보여줍니다:
와일드카드를 사용한 여러 쿼리 파라미터
여러 파라미터가 다양하게 변하는 검색 또는 필터 페이지의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    # Match search results with any query and page number
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/search?q=*&page=*,https://your-site.com/search?q=*&page=*&sort=*"

이렇게 하면 검색어, 페이지 번호, 정렬 옵션과 무관하게 모든 검색 결과 페이지를 함께 그룹화합니다.
경로 패턴과 쿼리 파라미터 패턴 결합
동적 경로와 쿼리 문자열을 모두 사용하는 애플리케이션의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/api/v1/users/*/profile?tab=*,
      https://your-site.com/dashboard/*/reports?year=*&month=*,
      https://your-site.com/catalog/*/items?filter=*

이 구성은 다음을 그룹화합니다:

탭이 서로 다른 사용자 프로필 페이지.
기간이 서로 다른 대시보드 보고서.
다양한 필터를 적용한 카탈로그 항목.

계층적 URL 패턴
여러 단계로 중첩된 리소스 구조의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/organizations/*/teams/*/members/*,
      https://your-site.com/projects/*/issues/*/comments,
      https://your-site.com/categories/*/subcategories/*/products/*

이 구성은 여러 경로 세그먼트가 변하는 깊이 중첩된 URL을 처리합니다.
리소스 ID가 있는 API 엔드포인트
리소스 식별자가 다양한 REST API 엔드포인트의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://api.your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://api.your-site.com/v1/customers/*/orders,
      https://api.your-site.com/v1/customers/*/orders/*,
      https://api.your-site.com/v2/resources/*/relationships/*,
      https://api.your-site.com/*/items?id=*

이 구성은 개별 ID가 아니라 리소스 유형을 기준으로 API 엔드포인트를 그룹화합니다.
로케일 및 언어 변형
언어 또는 리전 코드가 있는 국제화된 사이트의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/*/products/*,
      https://your-site.com/*/*/articles/*,
      https://*.your-site.com/content/*

이 구성은 다음을 그룹화합니다:

언어가 서로 다른 제품 페이지(/en/products/123, /fr/products/123).
언어 및 리전 코드가 있는 기사(/en/us/articles/guide).
서브도메인 기반 로케일(en.your-site.com/content/page).

세션 및 토큰 파라미터
그룹화해야 하는 세션 ID 또는 임시 토큰이 있는 URL의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/checkout?session=*,
      https://your-site.com/verify?token=*&email=*,
      https://your-site.com/share/*?ref=*

이 구성은 DAST가 고유한 세션이나 토큰마다 별도의 페이지로 취급하는 것을 방지합니다.
복잡한 이커머스 시나리오#
이커머스 사이트를 종합적으로 최적화하는 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://shop.your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://shop.your-site.com/products?category=*&brand=*&price=*,
      https://shop.your-site.com/products/*/reviews?page=*,
      https://shop.your-site.com/products/*/reviews?page=*&sort=*,
      https://shop.your-site.com/cart?item=*&quantity=*,
      https://shop.your-site.com/user/orders/*/tracking,
      https://shop.your-site.com/compare?products=*

이 구성은 다음을 처리합니다:

여러 필터 조합이 있는 제품 목록.
정렬 방식이 다른, 페이지가 나뉜 제품 리뷰.
장바구니 변형.
주문 추적 페이지.
제품 비교 페이지.

구체성에 따른 패턴 순서
패턴이 겹칠 때는 가장 구체적인 것부터 가장 일반적인 것 순으로 지정합니다:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    # Order matters: specific patterns first, general patterns last
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/products/*-premium-*/details,
      https://your-site.com/products/*-sale-*/details,
      https://your-site.com/products/*/details,
      https://your-site.com/products/*

이 구성은 프리미엄 제품과 세일 제품이 일반 제품 패턴으로 넘어가기 전에 별도로 그룹화되도록 보장합니다.
그룹화에서 특정 패턴 제외
DAST_SCOPE_EXCLUDE_URLS와 결합하여 특정 URL을 그룹화와 스캔에서 모두 제외합니다:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/articles/*/comments?page=*"
    # Exclude logout and admin URLs from scanning entirely
    DAST_SCOPE_EXCLUDE_URLS: "https://your-site.com/logout,https://your-site.com/admin/*"

이 구성은 기사 댓글 페이지를 그룹화하면서 로그아웃 및 관리자 URL은 스캔에서 제외합니다.

홈/GitLab/사용자/보안/Dast/Browser/Configuration/분석기 설정 커스터마이즈

`분석기 설정 커스터마이즈`

GitLab v19.5

원문 보기
번역일: 2026-09-18

요약
범위는 대상 애플리케이션을 크롤링할 때 DAST가 따라가는 URL을 제어합니다. DAST는 범위 내 URL을 따라가며 크롤링을 계속하기 위해 수행할 후속 액션을 DOM에서 검색합니다. DAST는 이미지, 스타일시트, 폰트, 스크립트, AJAX 요청과 같이 문서가 아닌 콘텐츠 유형에 대해서는 범위 외 URL을 따라갑니다.

`범위 관리#`


범위는 대상 애플리케이션을 크롤링할 때 DAST가 따라가는 URL을 제어합니다. 범위를 적절히 관리하면 대상 애플리케이션만 취약점 검사 대상이 되도록 보장하면서 스캔 실행 시간을 최소화할 수 있습니다.
범위 유형#
범위 유형은 세 가지입니다:

범위 내
범위 외
범위에서 제외

범위 내#
DAST는 범위 내 URL을 따라가며 크롤링을 계속하기 위해 수행할 후속 액션을 DOM에서 검색합니다.
기록된 범위 내 HTTP 메시지는 취약점이 있는지 패시브 검사되며, 전체 스캔을 실행할 때 공격을 구성하는 데 사용됩니다.
범위 외#
DAST는 이미지, 스타일시트, 폰트, 스크립트, AJAX 요청과 같이 문서가 아닌 콘텐츠 유형에 대해서는 범위 외 URL을 따라갑니다.
인증을 제외하면, DAST는 외부 웹사이트로의 링크를 클릭하는 경우와 같은 전체 페이지 로드에 대해서는 범위 외 URL을 따라가지 않습니다.
정보 유출을 검색하는 패시브 검사를 제외하면, 범위 외 URL에 대해 기록된 HTTP 메시지는 취약점 검사를 하지 않습니다.
범위에서 제외#
DAST는 범위에서 제외된 URL을 따라가지 않습니다. 정보 유출을 검색하는 패시브 검사를 제외하면, 범위에서 제외된 URL에 대해 기록된 HTTP 메시지는 취약점 검사를 하지 않습니다.
인증 중에 범위가 다르게 작동하는 방식#
많은 대상 애플리케이션은 싱글 사인온(SSO)에 ID 액세스 관리 공급자를 사용하는 경우처럼 외부 웹사이트에 의존하는 인증 프로세스를 갖고 있습니다.
DAST가 이러한 공급자로 인증할 수 있도록, DAST는 인증 중 전체 페이지 로드에 대해 범위 외 URL을 따라갑니다. DAST는 범위에서 제외된 URL은 따라가지 않습니다.
DAST가 HTTP 요청을 차단하는 방법#
DAST는 범위 규칙 때문에 요청을 차단할 때 브라우저에 평소와 같이 HTTP 요청을 하도록 지시합니다. 이후 요청은 인터셉트되어 BlockedByClient 이유로 거부됩니다.
이 접근 방식을 통해 DAST는 HTTP 요청이 대상 서버에 도달하지 않도록 하면서 그 요청을 기록할 수 있습니다. 200.1과 같은 패시브 검사는 이렇게 기록된 요청을 사용하여 외부 호스트로 전송된 정보를 검증합니다.
범위 구성 방법#
기본적으로 대상 애플리케이션의 호스트와 일치하는 URL은 범위 내로 간주됩니다. 다른 모든 호스트는 범위 외로 간주됩니다.
범위는 다음 변수로 구성합니다:

DAST_SCOPE_ALLOW_HOSTS를 사용하여 범위 내 호스트를 추가합니다.
DAST_SCOPE_IGNORE_HOSTS를 사용하여 범위 외 호스트에 추가합니다.
DAST_SCOPE_EXCLUDE_HOSTS를 사용하여 범위에서 제외된 호스트에 추가합니다.
DAST_SCOPE_EXCLUDE_URLS를 사용하여 특정 URL을 범위에서 제외로 설정합니다.

규칙:

호스트 제외가 호스트 무시보다 우선하며, 호스트 무시는 호스트 허용보다 우선합니다.
호스트에 대한 범위 구성은 해당 호스트의 서브도메인에 대한 범위를 구성하지 않습니다.
호스트에 대한 범위 구성은 해당 호스트의 모든 포트에 대한 범위를 구성하지 않습니다.

다음은 일반적인 구성의 예입니다:
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

취약점 탐지#
DAST는 종합적인 브라우저 기반 취약점 검사를 통해 취약점을 탐지합니다. 이러한 검사는 스캔 중에 웹 애플리케이션의 보안 이슈를 식별합니다.
크롤러는 DAST를 프록시 서버로 구성한 상태에서 브라우저로 대상 웹사이트를 실행합니다. 이를 통해
브라우저가 만드는 모든 요청과 응답이 DAST에 의해 패시브 스캔됩니다. 전체 스캔을 실행할 때,
DAST가 실행하는 액티브 취약점 검사는 브라우저를 사용하지 않습니다. 취약점을 검사하는 방식의 이러한
차이 때문에, 스캔이 의도한 대로 작동하도록 대상 웹사이트의 특정 기능을 비활성화해야 하는 문제가
발생할 수 있습니다.
예를 들어, Anti-CSRF 토큰이 있는 폼을 포함하는 대상 웹사이트의 경우, 브라우저가 사용자가 페이지를
보는 것과 같이 페이지와 폼을 표시하기 때문에 패시브 스캔은 의도한 대로 작동합니다. 그러나 전체 스캔에서
실행되는 액티브 취약점 검사는 Anti-CSRF 토큰이 포함된 폼을 제출할 수 없습니다.
이러한 경우에는 전체 스캔을 실행할 때 Anti-CSRF 토큰을 비활성화합니다.
스캔 시간 관리#
브라우저 기반 크롤러를 실행하면 표준 GitLab DAST 솔루션과 비교해 많은 웹 애플리케이션에서 더 나은 커버리지를 얻을 것으로 예상됩니다.
다만 스캔 시간이 늘어나는 비용이 수반될 수 있습니다.
다음 방법으로 커버리지와 스캔 시간 사이의 트레이드오프를 관리할 수 있습니다:

대상 애플리케이션에 템플릿 기반 페이지나 반복되는 콘텐츠가 있는 경우, DAST_CRAWL_GROUPED_URLS 변수로 URL을 그룹화할 수 있습니다.
러너를 수직 확장하고 변수 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입니다.

타임아웃#
네트워크 상태가 좋지 않거나 애플리케이션 부하가 심한 경우, 기본 타임아웃이 애플리케이션에 적합하지 않을 수 있습니다.
브라우저 기반 스캔은 한 페이지에서 다음 페이지로 전환할 때 원활하게 계속되도록 다양한 타임아웃을 조정하는 기능을 제공합니다. 이 값들은 Duration string으로 구성하며, 분은 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 기간 이후에 새로운 DOM(Document Object Model) 수정 이벤트가 없습니다.



이러한 이벤트가 발생한 후, 브라우저 기반 스캔은 페이지가 로드되어 준비된 것으로 간주하고 다음 액션을 시도합니다.
애플리케이션에 지연이 발생하거나 내비게이션 실패가 많이 반환되는 경우, 다음 예시와 같이 타임아웃 값을 조정하는 것을 고려합니다:
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"

Note
이 값들을 조정하면 각 브라우저가 여러 활동이 완료될 때까지 기다리는 시간이 조정되므로 스캔 시간에 영향을 줄 수 있습니다.

페이지 준비 타임아웃#
페이지 준비는 페이지가 완전히 로드되고 DOM이 안정화되어 인터랙티브 요소를 사용할 수 있는 상태를 말합니다. 올바른 페이지 준비 감지는 다음에 매우 중요합니다:

스캔 정확성: 페이지가 완전히 로드되기 전에 분석하면 콘텐츠를 놓치거나 거짓 음성이 발생할 수 있습니다.
크롤 효율성: 너무 오래 기다리면 스캔 시간이 낭비되고, 충분히 기다리지 않으면 동적 콘텐츠를 놓칩니다.
현대 웹 애플리케이션 지원: 싱글 페이지 애플리케이션, AJAX가 많은 사이트, 프로그레시브 로딩 패턴은 정교한 준비 감지가 필요합니다.

선택적으로 구성할 수 있는 타임아웃 시퀀스를 사용하여 DAST 스캐너는 페이지의 각 부분이 완전히 로드된 시점을 감지할 수 있습니다.
타임아웃 변수#
다음 CI/CD 변수를 사용하여 DAST 페이지 준비 타임아웃을 커스터마이즈합니다.
전체 목록은 사용 가능한 CI/CD 변수를 참고합니다.



타임아웃 변수
기본값
설명




DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT
15s
브라우저가 한 페이지에서 다른 페이지로 이동할 때까지 기다리는 최대 시간. 전체 페이지 로드의 문서 로드 단계에서 사용됩니다.


DAST_PAGE_READY_AFTER_ACTION_TIMEOUT
7s
브라우저가 페이지를 로드되어 분석할 준비가 된 것으로 간주할 때까지 기다리는 최대 시간. 전체 페이지 로드를 트리거하지 않는 페이지 내 액션에 대해 DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT의 대안으로 사용됩니다.


DAST_PAGE_DOM_STABLE_WAIT
500ms
페이지가 안정적인지 확인하기 전에 DOM 업데이트를 기다리는 시간을 정의합니다. 클라이언트 측 렌더링 단계 시작 시 사용됩니다.


DAST_PAGE_DOM_READY_TIMEOUT
6s
내비게이션이 완료된 후 브라우저가 페이지를 로드되어 분석할 준비가 된 것으로 간주할 때까지 기다리는 최대 시간. 백그라운드 데이터 가져오기와 DOM 렌더링 대기를 제어합니다.


DAST_PAGE_IS_LOADING_ELEMENT
없음
페이지에서 더 이상 표시되지 않을 때 분석기에 페이지 로딩이 완료되어 스캔을 계속할 수 있음을 알리는 선택자. 클라이언트 측 렌더링 프로세스의 끝을 나타냅니다.



페이지 로딩 워크플로#
현대 웹 애플리케이션은 여러 단계로 로드됩니다. DAST 스캐너는 이 과정의 각 단계마다 특정 타임아웃을
갖습니다:


문서 로딩: 브라우저가 기본 페이지 구조를 가져와 처리합니다.

서버에서 HTML 콘텐츠를 가져옵니다.
참조된 CSS 및 JavaScript 파일을 로드합니다.
콘텐츠를 파싱하고 초기 페이지를 렌더링합니다.
표준 "document ready" 이벤트를 트리거합니다.

이 단계에서는 문서 로딩의 최대 대기 시간을 설정하는 DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT(전체 페이지 로드의 경우) 또는 DAST_PAGE_READY_AFTER_ACTION_TIMEOUT(페이지 내 액션의 경우)을 사용합니다.


클라이언트 측 렌더링: 초기 로딩 이후, 많은 싱글 페이지 애플리케이션은 다음을 수행합니다:

초기 JavaScript 실행을 수행합니다(DAST_PAGE_DOM_STABLE_WAIT).
AJAX 또는 다른 API 호출로 백그라운드 데이터를 가져옵니다.
DOM을 렌더링하고 가져온 데이터를 기반으로 업데이트를 수행합니다(DAST_PAGE_DOM_READY_TIMEOUT).
페이지 로딩 표시기를 표시합니다(DAST_PAGE_IS_LOADING_ELEMENT).

스캐너는 이러한 활동을 모니터링하여 페이지가 인터랙션 준비가 된 시점을 판단합니다.


다음 차트는 페이지를 크롤링할 때 사용되는 타임아웃 순서를 보여줍니다:
Mermaid 다이어그램 (27줄)
소스 코드 보기
%%{init: {
  "gantt": {
    "leftPadding": 250,
    "sectionFontSize": 15,
    "topPadding": 40,
    "fontFamily": "GitLab Sans"
  }
}}%%
gantt
    accTitle: DAST timeout sequence during page load
    accDescr: Timeline showing when DAST timeout configurations apply during the two phases of page loading.
dateFormat YYYY-MM-DD
axisFormat  %d
section     Document load
DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT :done, nav1, 2024-01-01, 6d
Fetch HTML :active, nav1, 2024-01-01, 3d
Fetch CSS&amp;JS :active, nav1, 2024-01-04, 3d
DocumentReady :milestone, nav1, 2024-01-07, 0d

section     Load Data / Client-side render
DAST_PAGE_DOM_STABLE_WAIT :done, dom1, 2024-01-07, 3d
Initial JS Execution :active, dom1, 2024-01-07, 3d
DAST_PAGE_DOM_READY_TIMEOUT :done, ready1, 2024-01-10, 4d
Fetch Data :active, dom1, 2024-01-10, 2d
Render DOM :active, dom1, 2024-01-10, 2d
DAST_PAGE_IS_LOADING_ELEMENT :milestone, load1, 2024-01-14, 0d</code></pre></details></div>

그룹화된 URL#
웹사이트에 대해 DAST 스캐너를 실행하면 일반적인 스캔이 완료되기까지 몇 시간이 걸릴 수 있습니다.
이 지연은 웹사이트에 동일한 템플릿을 사용하면서 정보만 다른 유사한 페이지가 수천 개 포함되어 있을 때
발생합니다. DAST는 각 페이지를 별개로 취급해 개별 분석하므로, 이러한 유사한 페이지를 크롤링하는 데
스캔 시간의 대부분을 소비합니다.
예를 들어:

수천 개의 제품 페이지가 있는 이커머스 사이트(/products/item-123, /products/item-456)
사용자 프로필이 있는 소셜 플랫폼(/users/john, /users/jane)
분류된 기사가 있는 콘텐츠 관리 시스템(/blog/category/tech, /blog/category/news)
페이지가 나뉜 결과가 있는 검색 인터페이스(/search?q=term&page=1, /search?q=term&page=2)

모든 URL을 고유한 것으로 취급하는 대신, 그룹화된 URL을 사용하면 유사한 URL을 함께 묶는 와일드카드 패턴을
정의할 수 있습니다. DAST가 이러한 패턴과 일치하는 URL을 만나면, 보안 커버리지를 유지하면서 스캔 시간을 줄이기 위해
각 그룹에서 대표 URL 하나만 분석합니다.
예를 들어, 모든 제품 상세 페이지가 동일한 구조와 보안 모델을 따른다면 DAST는 그중 하나만 철저히
테스트하면 됩니다.
그룹화된 URL 작동 방식#
그룹화된 URL 패턴을 구성하면 DAST의 크롤러가 크롤을 최적화합니다:

패턴 매칭: 크롤러가 새 URL을 발견하면 정의한 패턴과 각각 대조합니다.
스마트 그룹화: 패턴과 일치하는 URL은 함께 그룹화되며, 처음 발견된 URL만 완전히
분석됩니다.
내비게이션 건너뜀: 동일한 패턴과 일치하는 후속 URL은 전체 크롤링에서 제외되지만 보고를 위해 여전히
기록됩니다.
보안 커버리지: 대표 URL에서 수행한 보안 분석이 그룹 전체에 적용됩니다.

Warning
그룹화된 URL 구성 때문에 건너뛴 URL이 크롤 그래프에서 visited 또는 failed로 표시될 수 있습니다. 이는 알려진 이슈입니다. 자세한 내용은
이슈 577252를 참고합니다.

구성 예시 가이드#
다음 예시는 가상의 이커머스 웹사이트를 사용합니다. 이 사이트에는 쿼리 파라미터로 다양한 필터를 받는 제품 목록 페이지와,
URL의 하위 경로에 제품 식별자가 들어가는 제품 상세 페이지가 있습니다.
애플리케이션의 URL 패턴 분석
그룹화된 URL을 구성하기 전에 애플리케이션의 URL 구조를 파악합니다:

사이트맵 또는 애플리케이션 경로를 검토합니다.
이전 스캔의 DAST 로그를 살펴 반복되는 패턴을 파악합니다.
URL을 기능적 목적(제품 페이지, 사용자 프로필, 검색 결과)별로 분류합니다.
동일한 페이지 구조를 공유하는 템플릿 기반 페이지를 파악합니다.

이 예시에서 이커머스 사이트를 스캔하면 CI 아티팩트에 있는 로그 파일에 다음 URL이 기록됩니다:
INF REPT  visited 8 URLs
INF REPT  URL visited: (DOC www.your-site.com/products?category=vegetables&sort=price) GET www.your-site.com/products?category=vegetables&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=fruits&sort=price) GET www.your-site.com/products?category=fruits&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=frozen&sort=price) GET www.your-site.com/products?category=frozen&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products?category=frozen&sort=price) GET www.your-site.com/products?category=frozen&sort=price
INF REPT  URL visited: (DOC www.your-site.com/products/029039-apple-93000/details) GET www.your-site.com/products/029039-apple-93000/details
INF REPT  URL visited: (DOC www.your-site.com/products/99345-orange-33322/details) GET www.your-site.com/products/99345-orange/details
INF REPT  URL visited: (DOC www.your-site.com/products/90845-orange-33992/details) GET www.your-site.com/products/90845-orange/details
INF REPT  URL visited: (DOC www.your-site.com/products/100232-bananas-2677/details) GET www.your-site.com/products/100232-bananas-2677/details

처음 네 URL은 category 및 sort 필터가 서로 다른 제품 목록 페이지입니다.
마지막 네 URL은 고유한 제품 식별자를 가진 개별 제품 상세 페이지입니다.
제품 상세 페이지 중 두 개는 식별자에 orange가 포함되어 있습니다.
이 두 종류의 페이지는 동일한 기본 템플릿과 보안 특성을 공유할 가능성이 높습니다.
그룹화된 URL로 최적화하지 않으면 DAST는 여덟 개 페이지를 모두 개별적으로 크롤링하고 테스트합니다.
와일드카드 패턴 설계
패턴을 만들 때는 다음 규칙을 따릅니다:

패턴 인식을 위해 * 와일드카드를 하나 이상 포함합니다. *는 URL에서 0개 이상의 문자와 일치합니다.
URL은 URL의 특정 부분이 아니라 문자 단위로 매칭됩니다. *는 URL의 하위 경로 두 개 이상과도 일치할 수 있습니다.
크롤 과정에서 URL의 어느 문자가 변하는지 찾습니다. 관련 없는 페이지까지 과도하게 묶이지 않도록 구체적으로 지정합니다.
패턴 순서를 고려합니다. 페이지가 여러 패턴과 일치하면 먼저 지정한 패턴이 사용됩니다.

이커머스 웹사이트의 패턴을 다음과 같이 구성합니다:

제품 카테고리 목록 그룹 패턴: 처음 네 URL은 www.your-site.com/products?category=*&sort=price 패턴으로
논리적으로 묶을 수 있습니다. 이 패턴은 카테고리 필터를 사용하면서 sort 필터로 price를 지정하는 모든
페이지와 일치합니다.
제품 상세 그룹 패턴: 마지막 네 URL은 www.your-site.com/products/*/details 패턴으로 논리적으로 묶을
수 있습니다. 이 패턴은 제품 식별자와 무관하게 모든 제품 상세 페이지와
일치합니다.

제품 상세 그룹 패턴을 두 그룹으로 더 나눌 수도 있습니다:

오렌지 제품 상세 그룹 패턴: www.your-site.com/products/*orange*/details 패턴은 오렌지에 해당하는 두 URL과 일치합니다.
일반 제품 상세 그룹 패턴: www.your-site.com/products/*/details 패턴은 그 외 모든 제품과 일치합니다.

한 페이지가 두 개 이상의 URL 패턴과 일치할 수 있습니다. 매칭하고자 하는 순서대로 패턴을 지정합니다. 예를 들어
www.your-site.com/products/4782-orange-777/details는 두 패턴 모두와 일치하지만, 이 페이지는 오렌지 제품 상세 페이지입니다.
오렌지 제품 상세 그룹 패턴과 일치하도록 하려면, 구성에서 일반 제품 상세 그룹 패턴보다 앞에 오렌지 제품 상세
패턴을 지정합니다.
DAST_CRAWL_GROUPED_URLS 변수 구성
.gitlab-ci.yml 파일에 다음 구성을 추가합니다:
include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/products?category=*&sort=price,https://your-site.com/products/*orange*/details,https://your-site.com/products/*/details"

모니터링 및 검증
그룹화된 URL을 구현한 후:

크롤 그래프(활성화한 경우)를 확인하여 그룹화 동작을 검증합니다. 크롤 그래프의 분기가 줄어들어야 합니다.
스캔 로그를 검토하여 예상한 URL 차단을 확인합니다. 방문된 URL이 줄어들어야 합니다.
보안 커버리지가 손상되지 않았는지 검증합니다. 그룹당 한 페이지만 취약점 스캔을 하므로 발견 건수가 줄어들 수 있습니다.
스캔 기간의 성능 향상을 측정합니다. 스캔이 끝나는 데 걸리는 시간이 줄어들어야 합니다.

고급 구성 예시#
다음 예시는 일반적인 웹 애플리케이션 시나리오에 적용할 수 있는 고급 패턴을 보여줍니다:
와일드카드를 사용한 여러 쿼리 파라미터
여러 파라미터가 다양하게 변하는 검색 또는 필터 페이지의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    # Match search results with any query and page number
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/search?q=*&page=*,https://your-site.com/search?q=*&page=*&sort=*"

이렇게 하면 검색어, 페이지 번호, 정렬 옵션과 무관하게 모든 검색 결과 페이지를 함께 그룹화합니다.
경로 패턴과 쿼리 파라미터 패턴 결합
동적 경로와 쿼리 문자열을 모두 사용하는 애플리케이션의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/api/v1/users/*/profile?tab=*,
      https://your-site.com/dashboard/*/reports?year=*&month=*,
      https://your-site.com/catalog/*/items?filter=*

이 구성은 다음을 그룹화합니다:

탭이 서로 다른 사용자 프로필 페이지.
기간이 서로 다른 대시보드 보고서.
다양한 필터를 적용한 카탈로그 항목.

계층적 URL 패턴
여러 단계로 중첩된 리소스 구조의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/organizations/*/teams/*/members/*,
      https://your-site.com/projects/*/issues/*/comments,
      https://your-site.com/categories/*/subcategories/*/products/*

이 구성은 여러 경로 세그먼트가 변하는 깊이 중첩된 URL을 처리합니다.
리소스 ID가 있는 API 엔드포인트
리소스 식별자가 다양한 REST API 엔드포인트의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://api.your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://api.your-site.com/v1/customers/*/orders,
      https://api.your-site.com/v1/customers/*/orders/*,
      https://api.your-site.com/v2/resources/*/relationships/*,
      https://api.your-site.com/*/items?id=*

이 구성은 개별 ID가 아니라 리소스 유형을 기준으로 API 엔드포인트를 그룹화합니다.
로케일 및 언어 변형
언어 또는 리전 코드가 있는 국제화된 사이트의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/*/products/*,
      https://your-site.com/*/*/articles/*,
      https://*.your-site.com/content/*

이 구성은 다음을 그룹화합니다:

언어가 서로 다른 제품 페이지(/en/products/123, /fr/products/123).
언어 및 리전 코드가 있는 기사(/en/us/articles/guide).
서브도메인 기반 로케일(en.your-site.com/content/page).

세션 및 토큰 파라미터
그룹화해야 하는 세션 ID 또는 임시 토큰이 있는 URL의 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/checkout?session=*,
      https://your-site.com/verify?token=*&email=*,
      https://your-site.com/share/*?ref=*

이 구성은 DAST가 고유한 세션이나 토큰마다 별도의 페이지로 취급하는 것을 방지합니다.
복잡한 이커머스 시나리오#
이커머스 사이트를 종합적으로 최적화하는 경우:
dast:
  variables:
    DAST_TARGET_URL: "https://shop.your-site.com"
    DAST_CRAWL_GROUPED_URLS: |
      https://shop.your-site.com/products?category=*&brand=*&price=*,
      https://shop.your-site.com/products/*/reviews?page=*,
      https://shop.your-site.com/products/*/reviews?page=*&sort=*,
      https://shop.your-site.com/cart?item=*&quantity=*,
      https://shop.your-site.com/user/orders/*/tracking,
      https://shop.your-site.com/compare?products=*

이 구성은 다음을 처리합니다:

여러 필터 조합이 있는 제품 목록.
정렬 방식이 다른, 페이지가 나뉜 제품 리뷰.
장바구니 변형.
주문 추적 페이지.
제품 비교 페이지.

구체성에 따른 패턴 순서
패턴이 겹칠 때는 가장 구체적인 것부터 가장 일반적인 것 순으로 지정합니다:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    # Order matters: specific patterns first, general patterns last
    DAST_CRAWL_GROUPED_URLS: |
      https://your-site.com/products/*-premium-*/details,
      https://your-site.com/products/*-sale-*/details,
      https://your-site.com/products/*/details,
      https://your-site.com/products/*

이 구성은 프리미엄 제품과 세일 제품이 일반 제품 패턴으로 넘어가기 전에 별도로 그룹화되도록 보장합니다.
그룹화에서 특정 패턴 제외
DAST_SCOPE_EXCLUDE_URLS와 결합하여 특정 URL을 그룹화와 스캔에서 모두 제외합니다:
dast:
  variables:
    DAST_TARGET_URL: "https://your-site.com"
    DAST_CRAWL_GROUPED_URLS: "https://your-site.com/articles/*/comments?page=*"
    # Exclude logout and admin URLs from scanning entirely
    DAST_SCOPE_EXCLUDE_URLS: "https://your-site.com/logout,https://your-site.com/admin/*"

이 구성은 기사 댓글 페이지를 그룹화하면서 로그아웃 및 관리자 URL은 스캔에서 제외합니다.