분석기 설정 커스터마이즈

요약

범위는 대상 애플리케이션을 크롤링할 때 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 요청이 대상 서버에 도달하지 않도록 하면서 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 URL은 기본적으로 범위 내로 간주
    DAST_SCOPE_ALLOW_HOSTS: "api.site.com:8443"       # API를 스캔에 포함
    DAST_SCOPE_IGNORE_HOSTS: "analytics.site.com"      # 스캔에서 analytics를 명시적으로 제외
    DAST_SCOPE_EXCLUDE_HOSTS: "ads.site.com"           # ads 서브도메인의 URL은 방문하지 않음
    DAST_SCOPE_EXCLUDE_URLS: "https://my.site.com/user/logout"  # 이 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이 크롤 그래프에서 방문됨 또는 실패로 표시될 수 있습니다. 이것은 알려진 이슈입니다. 자세한 내용은 이슈 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는 8개 페이지를 모두 개별적으로 크롤링하고 테스트합니다.
와일드카드 패턴 설계
패턴을 만들 때 다음 규칙을 따르세요:

패턴 인식을 위해 * 와일드카드를 하나 이상 포함합니다. *는 URL에서 0개 이상의 문자와 일치합니다.
URL은 URL의 특정 부분이 아닌 문자로 매칭됩니다. *는 URL의 하나 이상의 서브 경로와 일치할 수 있습니다.
크롤 중에 URL에서 변하는 문자를 찾습니다. 관련 없는 페이지를 과도하게 그룹화하지 않도록 구체적으로 지정합니다.
패턴 순서를 고려합니다. 페이지가 여러 패턴과 일치하면 지정된 첫 번째 패턴이 사용됩니다.

이커머스 웹사이트에 대한 패턴을 구성합니다:

제품 카테고리 목록 그룹 패턴: 처음 네 URL은 패턴 www.your-site.com/products?category=*&sort=price를 사용하여 논리적으로 그룹화할 수 있습니다. 이 패턴은 카테고리 필터와 price를 sort 필터로 정의하는 모든 페이지와 일치합니다.
제품 상세 그룹 패턴: 마지막 네 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"
    # 검색어와 페이지 번호에 관계없이 검색 결과를 매칭
    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"
    # 순서 중요: 구체적인 패턴 먼저, 일반적인 패턴 나중에
    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=*"
    # 로그아웃 및 관리자 URL을 스캔에서 완전히 제외
    DAST_SCOPE_EXCLUDE_URLS: "https://your-site.com/logout,https://your-site.com/admin/*"

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


Docs/GitLab/User/Application_security/Dast/Browser/Configuration/Customize_settings
분석기 설정 커스터마이즈
원문 보기
번역일: 2026-05-22
요약
범위는 대상 애플리케이션을 크롤링할 때 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 요청이 대상 서버에 도달하지 않도록 하면서 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 URL은 기본적으로 범위 내로 간주
    DAST_SCOPE_ALLOW_HOSTS: "api.site.com:8443"       # API를 스캔에 포함
    DAST_SCOPE_IGNORE_HOSTS: "analytics.site.com"      # 스캔에서 analytics를 명시적으로 제외
    DAST_SCOPE_EXCLUDE_HOSTS: "ads.site.com"           # ads 서브도메인의 URL은 방문하지 않음
    DAST_SCOPE_EXCLUDE_URLS: "https://my.site.com/user/logout"  # 이 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이 크롤 그래프에서 방문됨 또는 실패로 표시될 수 있습니다. 이것은 알려진 이슈입니다. 자세한 내용은 이슈 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는 8개 페이지를 모두 개별적으로 크롤링하고 테스트합니다.
와일드카드 패턴 설계
패턴을 만들 때 다음 규칙을 따르세요:

패턴 인식을 위해 * 와일드카드를 하나 이상 포함합니다. *는 URL에서 0개 이상의 문자와 일치합니다.
URL은 URL의 특정 부분이 아닌 문자로 매칭됩니다. *는 URL의 하나 이상의 서브 경로와 일치할 수 있습니다.
크롤 중에 URL에서 변하는 문자를 찾습니다. 관련 없는 페이지를 과도하게 그룹화하지 않도록 구체적으로 지정합니다.
패턴 순서를 고려합니다. 페이지가 여러 패턴과 일치하면 지정된 첫 번째 패턴이 사용됩니다.

이커머스 웹사이트에 대한 패턴을 구성합니다:

제품 카테고리 목록 그룹 패턴: 처음 네 URL은 패턴 www.your-site.com/products?category=*&sort=price를 사용하여 논리적으로 그룹화할 수 있습니다. 이 패턴은 카테고리 필터와 price를 sort 필터로 정의하는 모든 페이지와 일치합니다.
제품 상세 그룹 패턴: 마지막 네 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"
    # 검색어와 페이지 번호에 관계없이 검색 결과를 매칭
    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"
    # 순서 중요: 구체적인 패턴 먼저, 일반적인 패턴 나중에
    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=*"
    # 로그아웃 및 관리자 URL을 스캔에서 완전히 제외
    DAST_SCOPE_EXCLUDE_URLS: "https://your-site.com/logout,https://your-site.com/admin/*"

이 구성은 기사 댓글 페이지를 그룹화하면서 로그아웃 및 관리자 URL을 스캔에서 제외합니다.
목차
범위 관리범위 유형인증 중에 범위가 다르게 작동하는 방식DAST가 HTTP 요청을 차단하는 방법범위 구성 방법취약점 탐지스캔 시간 관리타임아웃페이지 준비 타임아웃그룹화된 URL그룹화된 URL 작동 방식구성 예시 가이드