InfoGrab Docs

인증

요약

완전한 커버리지를 위해 DAST 분석기는 테스트 중인 애플리케이션에 인증해야 합니다. DAST는 다음을 위해 인증이 필요합니다: DAST 작업은 가장 일반적으로 브라우저에서 로그인 양식을 채우고 제출하여 애플리케이션에 스스로 인증합니다.

완전한 커버리지를 위해 DAST 분석기는 테스트 중인 애플리케이션에 인증해야 합니다. 이를 위해서는 DAST CI/CD 작업에서 인증 자격 증명과 인증 방법을 구성해야 합니다.

DAST는 다음을 위해 인증이 필요합니다:

  • 실제 공격을 시뮬레이션하고 공격자가 악용할 수 있는 취약점을 식별합니다.
  • 인증 후에만 표시될 수 있는 사용자별 기능 및 사용자 지정 동작을 테스트합니다.

DAST 작업은 가장 일반적으로 브라우저에서 로그인 양식을 채우고 제출하여 애플리케이션에 스스로 인증합니다. 양식이 제출된 후 DAST 작업은 인증이 성공했는지 확인합니다. 인증에 성공하면 DAST 작업은 계속 진행하고 대상 애플리케이션을 크롤링할 때 재사용을 위해 자격 증명을 저장합니다. 실패하면 DAST 작업이 중지됩니다.

DAST가 지원하는 인증 방법은 다음과 같습니다:

  • 단일 단계 로그인 양식
  • 다단계 로그인 양식
  • 구성된 대상 URL 외부의 URL에 인증

인증 자격 증명을 선택할 때:

  • 프로덕션 시스템, 프로덕션 서버에 유효하거나 프로덕션 데이터에 접근하는 데 사용되는 자격 증명은 사용하지 마세요.
  • 프로덕션 서버에 대해 인증된 스캔을 실행하지 마세요. 인증된 스캔은 인증된 사용자가 수행할 수 있는 모든 기능을 수행할 수 있으며, 여기에는 데이터 수정 또는 삭제, 양식 제출, 링크 따라가기가 포함됩니다. 비프로덕션 시스템 또는 서버에 대해서만 인증된 스캔을 실행하세요.
  • DAST가 전체 애플리케이션을 테스트할 수 있는 자격 증명을 제공합니다.
  • 향후 참조를 위해 자격 증명의 만료 날짜를 메모합니다(있는 경우). 예를 들어 1Password와 같은 비밀번호 관리자를 사용합니다.

다음 다이어그램은 인증의 다양한 단계에서 인증 변수의 사용을 보여줍니다:

Mermaid 다이어그램 (34줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Authentication variables
    accDescr: A sequence diagram showing authentication variables at different stages of authentication.
    participant DAST
    participant Browser
    participant Target

Note over DAST,Target: Initialization
DAST->>Browser: Initialize browser with proxy
DAST->>Browser: Navigate to DAST_AUTH_URL
Browser->>Target: Load initial page
Target-->>Browser: Return page content (may not contain login form)

Note over DAST,Target: Process before-login actions
DAST->>Browser: Click elements specified in DAST_AUTH_BEFORE_LOGIN_ACTIONS
Browser->>Target: Send click actions
Target-->>Browser: Render login form (modal/page)

Note over DAST,Target: Authentication
DAST->>Browser: Fill DAST_AUTH_USERNAME & DAST_AUTH_PASSWORD
DAST->>Browser: Click "submit"
Browser->>Target: Submit form
Target-->>Browser: Process authentication
Target-->>Browser: Set auth tokens

Note over DAST,Target: Process after-login actions (if specified)
DAST->>Browser: Execute DAST_AUTH_AFTER_LOGIN_ACTIONS
Browser->>Target: Actions after login but before login verification

Note over DAST,Target: Verification
DAST->>Browser: Check URL matches DAST_AUTH_SUCCESS_IF_AT_URL (if configured)
DAST->>Browser: Check element exists DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND (if configured)
DAST-&gt;&gt;Browser: Check login form absent DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM (default is true)</code></pre></details></div>



시작하기#


Note


분석기의 인증이 여전히 작동하는지 주기적으로 확인해야 합니다. 애플리케이션의 변경으로 인해 시간이 지남에 따라 깨질 수 있기 때문입니다.




DAST 인증된 스캔을 실행하려면:


    

  • 인증에 대한 전제 조건을 읽습니다.
    • 

  • 대상 웹사이트를 업데이트하여 인증된 사용자의 랜딩 페이지로 설정합니다.
    • 

  • 로그인 양식에 사용자 이름, 비밀번호 및 제출 버튼이 단일 페이지에 있는 경우 CI/CD 변수를 사용하여 단일 단계 로그인 양식 인증을 구성합니다.
    • 

  • 로그인 양식의 사용자 이름과 비밀번호 필드가 다른 페이지에 있는 경우 CI/CD 변수를 사용하여 다단계 로그인 양식 인증을 구성합니다.
    • 

  • 스캔 중에 사용자가 로그아웃되지 않도록 합니다.
    • 



전제 조건#


    

  • 스캔 중에 인증할 사용자의 사용자 이름과 비밀번호가 있습니다.
    • 

  • DAST가 애플리케이션에 인증할 수 있는지 확인하기 위해 알려진 문제를 확인했습니다.
    • 

  • 양식 인증을 사용하는 경우 전제 조건을 충족했습니다.
    • 

  • 양식 인증 흐름에 시간 기반 일회용 비밀번호가 포함된 경우 추가 전제 조건을 충족했습니다.
    • 

  • 인증이 성공했는지 여부를 확인하는 방법에 대해 고려했습니다.
    • 



양식 인증#


    

  • 애플리케이션의 로그인 양식 URL을 알고 있습니다. 또는 인증 URL에서 로그인 양식으로 이동하는 방법을 알고 있습니다(로그인 양식으로 클릭하여 이동 참조).
    • 

  • DAST가 각각의 값을 입력하는 데 사용하는 사용자 이름과 비밀번호 HTML 필드의 선택자를 알고 있습니다.
    • 

  • 선택될 때 로그인 양식을 제출하는 요소의 선택자를 알고 있습니다.
    • 



TOTP 인증#


히스토리
  • 스캐너 버전 6.9에서 도입되었습니다.


    

  • 테스트 사용자의 TOTP 등록에 대한 시크릿 키를 Base32로 인코딩하여 갖고 있습니다.
    • 

  • 인증 제공자가 다음 TOTP 구성(Google Authenticator와 동일)을 지원하는지 확인했습니다:

      

    • HMAC 알고리즘: SHA-1
      • 

    • 시간 단계: 30초
      • 

    • 토큰 길이: 6
      • 

    

    • 

  • DAST가 생성된 TOTP 토큰을 입력하는 데 사용하는 TOTP 필드의 선택자를 알고 있습니다.
    • 

  • TOTP 토큰이 비밀번호와 별도로 제출되는 경우 TOTP 토큰을 제출하는 요소의 선택자를 알고 있습니다.
    • 



사용 가능한 CI/CD 변수#


DAST 인증 CI/CD 변수 목록은 인증 변수를 참조하세요.


DAST CI/CD 변수 테이블은 Rake 작업 bundle exec rake gitlab:dast_variables:compile_docs에 의해 생성됩니다. lib/gitlab/security/dast_variables.rb에 정의된 변수 메타데이터를 사용합니다.


대상 웹사이트 업데이트#


CI/CD 변수 DAST_TARGET_URL을 사용하여 정의된 대상 웹사이트는 DAST가 애플리케이션 크롤링을 시작하는 URL입니다.


인증된 스캔에서 최상의 크롤링 결과를 얻으려면 대상 웹사이트가 사용자가 인증된 후에만 접근 가능한 URL이어야 합니다.
보통 이는 사용자가 로그인한 후 도달하는 페이지의 URL입니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/dashboard/welcome"
    DAST_AUTH_URL: "https://example.com/login"



HTTP 인증 구성#


Basic 인증과 같은 HTTP 인증 체계를 사용하려면 DAST_AUTH_TYPE 값을 basic-digest로 설정할 수 있습니다.
Negotiate 또는 NTLM과 같은 다른 체계도 작동할 수 있지만 현재 자동화된 테스트 커버리지 부족으로 인해 공식적으로 지원되지 않습니다.


구성에는 DAST 작업에 대해 CI/CD 변수 DAST_AUTH_TYPE, DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD가 정의되어야 합니다. 고유한 로그인 URL이 없는 경우 DAST_AUTH_URL을 DAST_TARGET_URL과 동일한 URL로 설정합니다.


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_TYPE: "basic-digest"
    DAST_AUTH_URL: "https://example.com"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


단일 단계 로그인 양식 구성#


단일 단계 로그인 양식에는 모든 로그인 양식 요소가 단일 페이지에 있습니다.
구성에는 DAST 작업에 대해 CI/CD 변수 DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD, DAST_AUTH_PASSWORD_FIELD 및 DAST_AUTH_SUBMIT_FIELD가 정의되어야 합니다.


작업 정의 YAML에서 URL과 필드 선택자를 설정해야 합니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


다단계 로그인 양식 구성#


다단계 로그인 양식에는 두 페이지가 있습니다. 첫 번째 페이지에는 사용자 이름과 다음 제출 버튼이 있는 양식이 있습니다.
사용자 이름이 유효하면 이후 페이지의 두 번째 양식에는 비밀번호와 양식 제출 버튼이 있습니다.


구성에는 DAST 작업에 대해 다음 CI/CD 변수가 정의되어야 합니다:


    

  • DAST_AUTH_URL
    • 

  • DAST_AUTH_USERNAME
    • 

  • DAST_AUTH_USERNAME_FIELD
    • 

  • DAST_AUTH_FIRST_SUBMIT_FIELD
    • 

  • DAST_AUTH_PASSWORD
    • 

  • DAST_AUTH_PASSWORD_FIELD
    • 

  • DAST_AUTH_SUBMIT_FIELD.
    • 



작업 정의 YAML에서 URL과 필드 선택자를 설정해야 합니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_FIRST_SUBMIT_FIELD: "css:button[name=next]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


시간 기반 일회용 비밀번호(TOTP) 구성#


TOTP 구성에는 DAST 작업에 대해 다음 CI/CD 변수가 정의되어야 합니다:


    

  • DAST_AUTH_OTP_FIELD
    • 

  • DAST_AUTH_OTP_KEY
    • 



비밀번호가 제출된 후 TOTP 토큰이 자체 양식으로 제출되는 경우 이 변수도 정의해야 합니다:


    

  • DAST_AUTH_OTP_SUBMIT_FIELD
    • 



_FIELD 선택자 변수는 작업 정의 YAML에서 정의할 수 있습니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
    DAST_AUTH_OTP_FIELD: "name:otp"
    DAST_AUTH_OTP_SUBMIT_FIELD: "css:input[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_OTP_KEY를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


Single Sign-On (SSO) 구성#


사용자가 애플리케이션에 로그인할 수 있다면 대부분의 경우 DAST도 로그인할 수 있습니다.
SSO를 사용하는 애플리케이션도 마찬가지입니다. SSO 솔루션을 사용하는 애플리케이션은 단일 단계 또는 다단계 로그인 양식 구성 가이드를 사용하여 DAST 인증을 구성해야 합니다.


DAST는 사용자가 로그인하기 위해 외부 ID 공급자 사이트로 리디렉션되는 인증 프로세스를 지원합니다.
DAST 인증의 알려진 문제를 확인하여 SSO 인증 프로세스가 지원되는지 확인합니다.


Windows 통합 인증(Kerberos) 구성#


Windows 통합 인증(Kerberos)은 Windows 도메인 내에서 호스팅되는 LOB(Line of Business) 애플리케이션에 대한 일반적인 인증 메커니즘입니다. 사용자의 컴퓨터 로그인을 사용하여 자동 인증을 제공합니다.


이 인증 양식을 구성하려면 다음 단계를 수행합니다:


    

  1. IT/운영 팀의 도움을 받아 필요한 정보를 수집합니다.
    2. 

  2. .gitlab-ci.yml 파일에서 dast 작업 정의를 생성하거나 업데이트합니다.
    3. 

  3. 수집된 정보를 사용하여 예시 krb5.conf 파일을 채웁니다.
    4. 

  4. 필요한 작업 변수를 설정합니다.
    5. 

  5. 프로젝트 설정 페이지를 사용하여 필요한 시크릿 변수를 설정합니다.
    6. 

  6. 인증이 작동하는지 테스트하고 확인합니다.
    7. 



IT/운영 부서의 도움을 받아 다음 정보를 수집합니다:


    

  • Windows 도메인 또는 Kerberos Realm 이름(이름에 마침표가 있어야 합니다, 예: EXAMPLE.COM)
    • 

  • Windows/Kerberos 도메인 컨트롤러의 호스트 이름
    • 

  • Kerberos의 경우 인증 서버 이름. Windows 도메인의 경우 도메인 컨트롤러입니다.
    • 



krb5.conf 파일 생성:


[libdefaults]
  # Realm is another name for domain name
  default_realm = EXAMPLE.COM
  # These settings are not needed for Windows Domains
  # they support other Kerberos implementations
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    # Domain controller or KDC
    kdc = kdc.example.com
    # Domain controller or admin server
    admin_server = kdc.example.com
  }
[domain_realm]
  # Mapping DNS domains to realms/Windows domain
  # DNS domains provided by DAST_AUTH_NEGOTIATE_DELEGATION
  # should also be represented here (but without the wildcard)
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM



이 구성은 DAST_AUTH_NEGOTIATE_DELEGATION 변수를 사용합니다.
이 변수는 통합 인증을 허용하는 데 필요한 다음 Chromium 정책을 설정합니다:



이 변수의 설정은 Windows 도메인 또는 Kerberos 영역과 연결된 DNS 도메인입니다.
다음 형식으로 제공해야 합니다:


    

  • 소문자와 대문자 모두.
    • 

  • 와일드카드 패턴과 도메인 이름만.
    • 



예에서 Windows 도메인은 EXAMPLE.COM이고 DNS 도메인은 example.com입니다.
이는 DAST_AUTH_NEGOTIATE_DELEGATION에 대해 *.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM 값을 제공합니다.


작업 정의로 모두 결합합니다:


# This job will extend the dast job defined in
# the DAST template which must also be included.
dast:
  image:
    name: "$SECURE_ANALYZERS_PREFIX/dast:$DAST_VERSION$DAST_IMAGE_SUFFIX"
    docker:
      user: root
  variables:
    DAST_TARGET_URL: https://target.example.com
    DAST_AUTH_URL: https://target.example.com
    DAST_AUTH_TYPE: basic-digest
    DAST_AUTH_NEGOTIATE_DELEGATION: '*.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM'
    # Not shown -- DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD set via Settings -> CI -> Variables
  before_script:
    - KRB5_CONF='
[libdefaults]
  default_realm = EXAMPLE.COM
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    kdc = ad1.example.com
    admin_server = ad1.example.com
  }
[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
'
    - cat "$KRB5_CONF" > /etc/krb5.conf
    - echo '$DAST_AUTH_PASSWORD' | kinit $DAST_AUTH_USERNAME
    - klist



예상 출력:


작업 콘솔 출력에는 before 스크립트의 출력이 포함됩니다. 인증이 성공한 경우 다음과 유사하게 보입니다. 인증이 실패하면 스캔을 실행하지 않고 작업이 실패해야 합니다.


Password for mike@EXAMPLE.COM:
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mike@EXAMPLE.COM

Valid starting       Expires              Service principal
11/11/2024 21:50:50  11/12/2024 07:50:50  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 11/12/2024 21:50:50



DAST 스캐너도 다음을 출력하여 성공을 나타냅니다:


2024-11-08T17:03:09.226 INF AUTH  attempting to authenticate find_auth_fields="basic-digest"
2024-11-08T17:03:09.226 INF AUTH  loading login page LoginURL="https://target.example.com"
2024-11-08T17:03:10.619 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (auto-detected)"
2024-11-08T17:03:10.619 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 want="HTTP status code < 400" url="https://target.example.com/"
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, did not detect a login form want="no login form found (auto-detected)"
2024-11-08T17:03:10.623 INF AUTH  authentication token cookies names=""
2024-11-08T17:03:10.623 INF AUTH  authentication token storage events keys=""
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, basic authentication detected want="has authentication token"
2024-11-08T17:03:11.230 INF AUTH  login attempt succeeded



로그인 양식으로 클릭하여 이동#


DAST_AUTH_URL에서 클릭할 요소의 경로를 제공하려면 DAST_AUTH_BEFORE_LOGIN_ACTIONS를 정의하여 DAST가 로그인 양식에 액세스할 수 있도록 합니다. 이 방법은 팝업(모달) 창에 로그인 양식을 표시하거나 로그인 양식에 고유한 URL이 없는 애플리케이션에 적합합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_BEFORE_LOGIN_ACTIONS: "css:.navigation-menu,css:.login-menu-item"



로그인 양식 제출 후 추가 작업 수행#


인증 세부 정보가 기록될 때 로그인 양식을 제출한 후, 확인 전에 수행할 작업 시퀀스를 제공하려면 DAST_AUTH_AFTER_LOGIN_ACTIONS를 정의합니다.
이는 "로그인 상태 유지" 대화 상자를 건너뛰는 데 사용할 수 있습니다.






작업
형식






요소 클릭
click(on=<selector>)




드롭다운에서 옵션 선택
select(option=<selector>)






작업은 쉼표로 구분됩니다. 선택자에 대한 정보는 요소의 선택자 찾기를 참조하세요.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_AFTER_LOGIN_ACTIONS: "select(option=id:accept-yes),click(on=id:continue-button)"



로그아웃 URL 제외#


DAST가 인증된 스캔을 실행하는 동안 로그아웃 URL을 크롤링하면 사용자가 로그아웃되어 나머지 스캔이 인증되지 않은 상태가 됩니다.
따라서 CI/CD 변수 DAST_SCOPE_EXCLUDE_URLS를 사용하여 로그아웃 URL을 제외하는 것이 좋습니다. DAST는 제외된 URL에 액세스하지 않으므로 사용자가 로그인 상태를 유지합니다.


제공된 URL은 절대 URL이거나 DAST_TARGET_URL의 기본 경로에 상대적인 URL 경로의 정규식일 수 있습니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/welcome/home"
    DAST_SCOPE_EXCLUDE_URLS: "https://example.com/logout,/user/.*/logout"



요소의 선택자 찾기#


선택자는 CI/CD 변수에서 브라우저의 페이지에 표시된 요소의 위치를 지정하는 데 사용됩니다.
선택자의 형식은 유형:검색 문자열입니다. DAST는 유형을 기반으로 검색 문자열을 사용하여 선택자를 검색합니다.






선택자 유형
예시
설명






css
css:.password-field
제공된 CSS 선택자를 가진 HTML 요소를 검색합니다. 성능상의 이유로 선택자는 가능한 한 구체적이어야 합니다.




id
id:element
제공된 요소 ID를 가진 HTML 요소를 검색합니다.




name
name:element
제공된 요소 이름을 가진 HTML 요소를 검색합니다.




xpath
xpath://input[@id="my-button"]/a
제공된 XPath를 가진 HTML 요소를 검색합니다. XPath 검색은 다른 검색보다 성능이 낮을 것으로 예상됩니다.






Google Chrome으로 선택자 찾기#


Chrome DevTools 요소 선택자 도구는 선택자를 찾는 효과적인 방법입니다.


    

  1. Chrome을 열고 선택자를 찾을 페이지(예: 사이트의 로그인 페이지)로 이동합니다.
    2. 

  2. macOS에서는 키보드 단축키 Command+Shift+C를, Windows 또는 Linux에서는 Control+Shift+C를 사용하여 Chrome DevTools의 Elements 탭을 엽니다.
    3. 

  3. 페이지에서 요소를 선택하여 검사 도구를 선택합니다.
search-elements
    4. 

  4. 선택자를 알고 싶은 페이지의 필드를 선택합니다.
    5. 

  5. 도구가 활성화된 후 세부 정보를 보고 싶은 필드를 강조 표시합니다.
highlight
    6. 

  6. 강조 표시되면 선택자의 좋은 후보가 될 수 있는 속성을 포함한 요소의 세부 정보를 볼 수 있습니다.
    7. 



이 예에서 id="user_login"이 좋은 후보로 보입니다. DAST_AUTH_USERNAME_FIELD: "id:user_login"으로 설정하여 DAST 사용자 이름 필드의 선택자로 사용할 수 있습니다.


올바른 선택자 선택#


선택자를 신중하게 선택하면 애플리케이션이 변경되어도 스캔이 탄력적으로 작동합니다.


선택 우선순위에 따라 다음을 선택자로 선택해야 합니다:


    

  • id 필드. 이 필드는 일반적으로 페이지에서 고유하며 거의 변경되지 않습니다.
    • 

  • name 필드. 이 필드는 일반적으로 페이지에서 고유하며 거의 변경되지 않습니다.
    • 

  • 사용자 이름 필드의 username 클래스에 대한 선택자 "css:.username"과 같이 필드에 특정한 class 값.
    • 

  • 사용자 이름 필드에 data-username 필드가 어떤 값을 가질 때 선택자 "css:[data-username]"과 같이 필드별 데이터 속성의 존재.
    • 

  • username 클래스를 가진 요소가 여러 개 있지만 login-form 클래스를 가진 요소 안에 하나만 중첩된 경우 선택자 "css:.login-form .username"과 같이 여러 class 계층 값.
    • 



특정 필드를 찾기 위해 선택자를 사용할 때 다음 항목을 검색하지 않아야 합니다:


    

  • 동적으로 생성되는 id, name, attribute, class 또는 value.
    • 

  • column-10 및 dark-grey와 같은 일반적인 클래스 이름.
    • 

  • 다른 선택자 검색보다 성능이 낮은 XPath 검색.
    • 

  • css:* 및 xpath://*로 시작하는 범위 없는 검색.
    • 



인증 성공 확인#


DAST가 로그인 양식을 제출한 후 인증이 성공했는지 확인하는 검증 프로세스가 수행됩니다. 인증에 실패하면 오류와 함께 스캔이 중지됩니다.


로그인 양식 제출 후 다음과 같은 경우 인증이 실패한 것으로 판단됩니다:


    

  • 로그인 제출 HTTP 응답에 400 또는 500 시리즈 상태 코드가 있습니다.
    • 

  • 어떤 확인 검사가 실패합니다.
    • 

  • 인증 프로세스 중에 충분히 무작위 값을 가진 인증 토큰이 설정되지 않습니다.
    • 



확인 검사#


확인 검사는 인증이 완료되면 브라우저 상태를 확인하여 인증이 성공했는지 추가로 확인합니다.


확인 검사가 구성되지 않은 경우 DAST는 로그인 양식의 부재를 테스트합니다.


URL을 기반으로 확인#


로그인 양식이 성공적으로 제출된 후 브라우저 탭에 표시되는 URL로 DAST_AUTH_SUCCESS_IF_AT_URL을 정의합니다.


DAST는 인증 후 브라우저의 URL과 확인 URL을 비교합니다.
동일하지 않으면 인증이 실패합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_AT_URL: "https://example.com/user/welcome"



요소의 존재를 기반으로 확인#


로그인 양식이 성공적으로 제출된 후 표시되는 페이지에서 하나 이상의 요소를 찾는 선택자로 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND를 정의합니다. 요소가 발견되지 않으면 인증이 실패합니다.
로그인이 실패할 때 표시되는 페이지에서 선택자를 검색하면 결과가 없어야 합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND: "css:.welcome-user"



로그인 양식의 부재를 기반으로 확인#


DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM을 "true"로 정의하여 로그인 양식이 성공적으로 제출된 후 표시되는 페이지에서 DAST가 로그인 양식을 검색해야 함을 나타냅니다. 로그인 후 로그인 양식이 여전히 있으면 인증이 실패합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM: "true"



인증 토큰#


DAST는 인증 프로세스 중에 설정된 인증 토큰을 기록합니다.
사용자가 스캔 전반에 걸쳐 로그인 상태를 유지할 수 있도록 DAST가 새 브라우저를 열 때 인증 토큰이 로드됩니다.


토큰을 기록하기 위해 DAST는 인증 프로세스 전에 애플리케이션에서 설정한 쿠키, 로컬 스토리지 및 세션 스토리지 값의 스냅샷을 찍습니다. DAST는 인증 후에도 동일한 작업을 수행하고 차이를 사용하여 인증 프로세스에 의해 생성된 것을 확인합니다.


DAST는 충분히 "무작위" 값으로 설정된 쿠키, 로컬 스토리지 및 세션 스토리지 값을 인증 토큰으로 간주합니다.
예를 들어 sessionID=HVxzpS8GzMlPAc2e39uyIVzwACIuGe0H는 인증 토큰으로 간주되지만 ab_testing_group=A1은 그렇지 않습니다.


CI/CD 변수 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 쿠키의 이름을 지정하고 DAST에서 사용하는 무작위성 검사를 우회할 수 있습니다.
이렇게 하면 인증 프로세스가 더 강력해질 뿐만 아니라 인증 토큰을 검사하는 검사의 취약성 검사 정확도도 향상될 수 있습니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_COOKIE_NAMES: "sessionID,refreshToken"



알려진 문제#


    

  • 인증 흐름에 CAPTCHA가 포함된 경우 DAST는 CAPTCHA를 우회할 수 없습니다.
테스트 환경에서 스캔 중인 애플리케이션의 구성된 사용자에 대해 이를 비활성화합니다.
    • 

  • DAST는 SMS 또는 생체 인식을 사용하여 일회용 비밀번호(OTP)로 인증할 수 없습니다.
테스트 환경에서 스캔 중인 애플리케이션의 구성된 사용자에 대해 이를 비활성화하거나 사용자의 MFA 유형을 TOTP로 변경합니다.
    • 

  • DAST는 로그인 중에 인증 토큰을 설정하지 않는 애플리케이션에 인증할 수 없습니다.
    • 

  • DAST는 사용자 이름, 비밀번호 및 선택적 TOTP보다 많은 텍스트 입력이 필요한 애플리케이션에 인증할 수 없습니다.
    • 



문제 해결#


로그는 인증 프로세스 중에 DAST가 무엇을 하고 무엇을 기대하는지에 대한 통찰력을 제공합니다. 자세한 정보는 인증 보고서를 구성하세요.


특정 오류 메시지나 상황에 대한 자세한 내용은 알려진 문제를 참조하세요.


브라우저 기반 분석기는 사용자를 인증하는 데 사용됩니다. 고급 문제 해결은 브라우저 기반 문제 해결을 참조하세요.


로그 읽기#


DAST CI/CD 작업의 콘솔 출력은 AUTH 로그 모듈을 사용하여 인증 프로세스에 대한 정보를 표시합니다.
예를 들어 다음 로그는 다단계 로그인 양식에 대한 실패한 인증을 보여줍니다.
로그인 후 홈 페이지가 표시되어야 하는데 대신 로그인 양식이 여전히 있었기 때문에 인증이 실패했습니다.


2022-11-16T13:43:02.000 INF AUTH  attempting to authenticate
2022-11-16T13:43:02.000 INF AUTH  loading login page LoginURL=https://example.com/login
2022-11-16T13:43:10.000 INF AUTH  multi-step authentication detected
2022-11-16T13:43:15.000 INF AUTH  verifying if user submit was successful true_when="HTTP status code < 400"
2022-11-16T13:43:15.000 INF AUTH  requirement is satisfied, no login HTTP message detected want="HTTP status code < 400"
2022-11-16T13:43:20.000 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-24T14:43:20.000 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 url=https://example.com/user/login?error=invalid%20credentials want="HTTP status code < 400"
2022-11-16T13:43:21.000 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-16T13:43:21.000 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"



인증 보고서 구성#


Warning


인증 보고서에는 로그인을 수행하는 데 사용된 자격 증명과 같은 민감한 정보가 포함될 수 있습니다.




인증 보고서는 인증 실패의 원인을 이해하는 데 도움이 되도록 CI/CD 작업 아티팩트로 저장될 수 있습니다.


보고서에는 로그인 프로세스 중에 수행된 단계, HTTP 요청 및 응답, DOM(Document Object Model) 및 스크린샷이 포함됩니다.


dast-auth-report


인증 디버그 보고서를 내보내는 예시 구성은 다음과 같을 수 있습니다:


dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_REPORT: "true"



알려진 문제#


로그인 양식을 찾을 수 없음#


DAST가 로그인 페이지를 로드할 때 로그인 양식을 찾지 못했습니다. 인증 URL을 로드할 수 없는 경우가 많습니다.
로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T12:44:02.838 INF AUTH  loading login page LoginURL=[authentication URL]
2022-12-07T12:44:11.119 FTL MAIN  authentication failed: login form not found



권장 조치:


    

  • 인증 보고서를 생성하여 HTTP 응답을 검사합니다.
    • 

  • 대상 애플리케이션 인증이 배포되고 실행 중인지 확인합니다.
    • 

  • DAST_AUTH_URL이 올바른지 확인합니다.
    • 

  • GitLab Runner가 DAST_AUTH_URL에 액세스할 수 있는지 확인합니다.
    • 

  • 사용된 경우 DAST_AUTH_BEFORE_LOGIN_ACTIONS가 유효한지 확인합니다.
    • 



스캔이 인증된 페이지를 크롤링하지 않음#


DAST가 인증 프로세스 중에 잘못된 인증 토큰을 캡처하면 스캔이 인증된 페이지를 크롤링할 수 없습니다. 쿠키 및 스토리지 인증 토큰의 이름이 로그에 기록됩니다. 예를 들어:


2022-11-24T14:42:31.492 INF AUTH  authentication token cookies names=["sessionID"]
2022-11-24T14:42:31.492 INF AUTH  authentication token storage events keys=["token"]



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 로그인이 예상대로 작동했는지 확인합니다.
    • 

  • 로그된 인증 토큰이 애플리케이션에서 사용하는 것인지 확인합니다.
    • 

  • 인증 토큰을 쿠키에 저장하는 경우 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 토큰 쿠키의 이름을 설정합니다.
    • 



선택자로 요소를 찾을 수 없음#


DAST가 사용자 이름, 비밀번호, 첫 번째 제출 버튼 또는 제출 버튼 요소를 찾지 못했습니다. 로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T13:14:11.545 FTL MAIN  authentication failed: unable to find elements with selector: css:#username



권장 조치:


    

  • 인증 보고서를 생성하여 Login page의 스크린샷을 사용하여 페이지가 올바르게 로드되었는지 확인합니다.
    • 

  • 브라우저에서 로그인 페이지를 로드하고 DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD_FIELD, DAST_AUTH_FIRST_SUBMIT_FIELD 및 DAST_AUTH_SUBMIT_FIELD에 구성된 선택자가 올바른지 확인합니다.
    • 



사용자 인증 실패#


DAST가 로그인 확인 검사 실패로 인해 인증에 실패했습니다. 로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T06:39:49.483 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.484 INF AUTH  requirement is satisfied, HTTP login request returned status code 303 url=http://auth-manual:8090/login want="HTTP status code < 400"
2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.589 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"
2022-12-07T06:39:53.626 FTL MAIN  authentication failed: failed to authenticate user



권장 조치:


    

  • 로그에서 requirement is unsatisfied를 찾습니다. 적절한 오류에 대응합니다.
    • 



요건 미충족, 로그인 양식 발견됨#


애플리케이션은 일반적으로 사용자가 로그인하면 대시보드를 표시하고 사용자 이름이나 비밀번호가 잘못된 경우 오류 메시지와 함께 로그인 양식을 표시합니다.


이 오류는 DAST가 사용자를 인증한 후 표시된 페이지에서 로그인 양식을 감지하면 발생하여 로그인 시도가 실패했음을 나타냅니다.


2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"



권장 조치:


    

  • 사용된 사용자 이름과 비밀번호/인증 자격 증명이 올바른지 확인합니다.
    • 

  • 인증 보고서를 생성하고 Login submit에 대한 Request가 올바른지 확인합니다.
    • 

  • 인증 보고서 Login submit 요청 및 응답이 비어 있을 수 있습니다. 이는 HTML 양식을 제출할 때 전체 페이지 재로드를 일으키는 요청이 없을 때 발생합니다. 웹소켓이나 AJAX를 사용하여 로그인 양식을 제출할 때 발생합니다.
    • 

  • 사용자 인증 후 표시되는 페이지에 로그인 양식 선택자와 일치하는 요소가 실제로 있는 경우 DAST_AUTH_SUCCESS_IF_AT_URL 또는 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND를 구성하여 로그인 시도를 확인하는 다른 방법을 사용합니다.
    • 



요건 미충족, 선택자 결과 없음#


DAST가 사용자 로그인 후 표시된 페이지에서 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND에 제공된 선택자와 일치하는 요소를 찾을 수 없습니다.


2022-12-07T06:39:33.239 INF AUTH  requirement is unsatisfied, searching DOM using selector returned no results want="has element css:[name=welcome]"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 예상 페이지가 표시되는지 확인합니다.
    • 

  • DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND 선택자가 올바른지 확인합니다.
    • 



요건 미충족, 브라우저가 URL에 없음#


DAST가 사용자 로그인 후 표시된 페이지의 URL이 DAST_AUTH_SUCCESS_IF_AT_URL에 따라 예상된 것과 다름을 감지했습니다.


2022-12-07T11:28:00.241 INF AUTH  requirement is unsatisfied, browser is not at URL browser_url="https://example.com/home" want="is at url https://example.com/user/dashboard"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 예상 페이지가 표시되는지 확인합니다.
    • 

  • DAST_AUTH_SUCCESS_IF_AT_URL이 올바른지 확인합니다.
    • 



요건 미충족, HTTP 로그인 요청 상태 코드#


로그인 양식을 로드하거나 양식을 제출할 때의 HTTP 응답이 400(클라이언트 오류) 또는 500(서버 오류) 상태 코드를 가졌습니다.


2022-12-07T06:39:53.626 INF AUTH  requirement is unsatisfied, HTTP login request returned status code 502 url="https://example.com/user/login" want="HTTP status code < 400"



    

  • 사용된 사용자 이름과 비밀번호/인증 자격 증명이 올바른지 확인합니다.
    • 

  • 인증 보고서를 생성하고 Login submit에 대한 Request가 올바른지 확인합니다.
    • 

  • 대상 애플리케이션이 예상대로 작동하는지 확인합니다.
    • 



요건 미충족, 인증 토큰 없음#


DAST가 인증 프로세스 중에 생성된 인증 토큰을 감지할 수 없었습니다.


2022-12-07T11:25:29.010 INF AUTH  authentication token cookies names=[]
2022-12-07T11:25:29.010 INF AUTH  authentication token storage events keys=[]
2022-12-07T11:25:29.010 INF AUTH  requirement is unsatisfied, no basic authentication, cookie or storage event authentication token detected want="has authentication token"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 로그인이 예상대로 작동했는지 확인합니다.
    • 

  • 브라우저의 개발자 도구를 사용하여 로그인하는 동안 생성된 쿠키 및 로컬/세션 스토리지 객체를 조사합니다. 충분히 무작위 값으로 생성된 인증 토큰이 있는지 확인합니다.
    • 

  • 인증 토큰을 쿠키에 저장하는 경우 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 토큰 쿠키의 이름을 설정합니다.
    •

인증

원문 보기
요약

완전한 커버리지를 위해 DAST 분석기는 테스트 중인 애플리케이션에 인증해야 합니다. DAST는 다음을 위해 인증이 필요합니다: DAST 작업은 가장 일반적으로 브라우저에서 로그인 양식을 채우고 제출하여 애플리케이션에 스스로 인증합니다.

완전한 커버리지를 위해 DAST 분석기는 테스트 중인 애플리케이션에 인증해야 합니다. 이를 위해서는 DAST CI/CD 작업에서 인증 자격 증명과 인증 방법을 구성해야 합니다.

DAST는 다음을 위해 인증이 필요합니다:

  • 실제 공격을 시뮬레이션하고 공격자가 악용할 수 있는 취약점을 식별합니다.
  • 인증 후에만 표시될 수 있는 사용자별 기능 및 사용자 지정 동작을 테스트합니다.

DAST 작업은 가장 일반적으로 브라우저에서 로그인 양식을 채우고 제출하여 애플리케이션에 스스로 인증합니다. 양식이 제출된 후 DAST 작업은 인증이 성공했는지 확인합니다. 인증에 성공하면 DAST 작업은 계속 진행하고 대상 애플리케이션을 크롤링할 때 재사용을 위해 자격 증명을 저장합니다. 실패하면 DAST 작업이 중지됩니다.

DAST가 지원하는 인증 방법은 다음과 같습니다:

  • 단일 단계 로그인 양식
  • 다단계 로그인 양식
  • 구성된 대상 URL 외부의 URL에 인증

인증 자격 증명을 선택할 때:

  • 프로덕션 시스템, 프로덕션 서버에 유효하거나 프로덕션 데이터에 접근하는 데 사용되는 자격 증명은 사용하지 마세요.
  • 프로덕션 서버에 대해 인증된 스캔을 실행하지 마세요. 인증된 스캔은 인증된 사용자가 수행할 수 있는 모든 기능을 수행할 수 있으며, 여기에는 데이터 수정 또는 삭제, 양식 제출, 링크 따라가기가 포함됩니다. 비프로덕션 시스템 또는 서버에 대해서만 인증된 스캔을 실행하세요.
  • DAST가 전체 애플리케이션을 테스트할 수 있는 자격 증명을 제공합니다.
  • 향후 참조를 위해 자격 증명의 만료 날짜를 메모합니다(있는 경우). 예를 들어 1Password와 같은 비밀번호 관리자를 사용합니다.

다음 다이어그램은 인증의 다양한 단계에서 인증 변수의 사용을 보여줍니다:

Mermaid 다이어그램 (34줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Authentication variables
    accDescr: A sequence diagram showing authentication variables at different stages of authentication.
    participant DAST
    participant Browser
    participant Target

Note over DAST,Target: Initialization
DAST-&gt;&gt;Browser: Initialize browser with proxy
DAST-&gt;&gt;Browser: Navigate to DAST_AUTH_URL
Browser-&gt;&gt;Target: Load initial page
Target--&gt;&gt;Browser: Return page content (may not contain login form)

Note over DAST,Target: Process before-login actions
DAST-&gt;&gt;Browser: Click elements specified in DAST_AUTH_BEFORE_LOGIN_ACTIONS
Browser-&gt;&gt;Target: Send click actions
Target--&gt;&gt;Browser: Render login form (modal/page)

Note over DAST,Target: Authentication
DAST-&gt;&gt;Browser: Fill DAST_AUTH_USERNAME &amp; DAST_AUTH_PASSWORD
DAST-&gt;&gt;Browser: Click "submit"
Browser-&gt;&gt;Target: Submit form
Target--&gt;&gt;Browser: Process authentication
Target--&gt;&gt;Browser: Set auth tokens

Note over DAST,Target: Process after-login actions (if specified)
DAST-&gt;&gt;Browser: Execute DAST_AUTH_AFTER_LOGIN_ACTIONS
Browser-&gt;&gt;Target: Actions after login but before login verification

Note over DAST,Target: Verification
DAST-&gt;&gt;Browser: Check URL matches DAST_AUTH_SUCCESS_IF_AT_URL (if configured)
DAST-&gt;&gt;Browser: Check element exists DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND (if configured)
DAST-&gt;&gt;Browser: Check login form absent DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM (default is true)</code></pre></details></div>



시작하기#


Note


분석기의 인증이 여전히 작동하는지 주기적으로 확인해야 합니다. 애플리케이션의 변경으로 인해 시간이 지남에 따라 깨질 수 있기 때문입니다.




DAST 인증된 스캔을 실행하려면:


    

  • 인증에 대한 전제 조건을 읽습니다.
    • 

  • 대상 웹사이트를 업데이트하여 인증된 사용자의 랜딩 페이지로 설정합니다.
    • 

  • 로그인 양식에 사용자 이름, 비밀번호 및 제출 버튼이 단일 페이지에 있는 경우 CI/CD 변수를 사용하여 단일 단계 로그인 양식 인증을 구성합니다.
    • 

  • 로그인 양식의 사용자 이름과 비밀번호 필드가 다른 페이지에 있는 경우 CI/CD 변수를 사용하여 다단계 로그인 양식 인증을 구성합니다.
    • 

  • 스캔 중에 사용자가 로그아웃되지 않도록 합니다.
    • 



전제 조건#


    

  • 스캔 중에 인증할 사용자의 사용자 이름과 비밀번호가 있습니다.
    • 

  • DAST가 애플리케이션에 인증할 수 있는지 확인하기 위해 알려진 문제를 확인했습니다.
    • 

  • 양식 인증을 사용하는 경우 전제 조건을 충족했습니다.
    • 

  • 양식 인증 흐름에 시간 기반 일회용 비밀번호가 포함된 경우 추가 전제 조건을 충족했습니다.
    • 

  • 인증이 성공했는지 여부를 확인하는 방법에 대해 고려했습니다.
    • 



양식 인증#


    

  • 애플리케이션의 로그인 양식 URL을 알고 있습니다. 또는 인증 URL에서 로그인 양식으로 이동하는 방법을 알고 있습니다(로그인 양식으로 클릭하여 이동 참조).
    • 

  • DAST가 각각의 값을 입력하는 데 사용하는 사용자 이름과 비밀번호 HTML 필드의 선택자를 알고 있습니다.
    • 

  • 선택될 때 로그인 양식을 제출하는 요소의 선택자를 알고 있습니다.
    • 



TOTP 인증#


히스토리
  • 스캐너 버전 6.9에서 도입되었습니다.


    

  • 테스트 사용자의 TOTP 등록에 대한 시크릿 키를 Base32로 인코딩하여 갖고 있습니다.
    • 

  • 인증 제공자가 다음 TOTP 구성(Google Authenticator와 동일)을 지원하는지 확인했습니다:

      

    • HMAC 알고리즘: SHA-1
      • 

    • 시간 단계: 30초
      • 

    • 토큰 길이: 6
      • 

    

    • 

  • DAST가 생성된 TOTP 토큰을 입력하는 데 사용하는 TOTP 필드의 선택자를 알고 있습니다.
    • 

  • TOTP 토큰이 비밀번호와 별도로 제출되는 경우 TOTP 토큰을 제출하는 요소의 선택자를 알고 있습니다.
    • 



사용 가능한 CI/CD 변수#


DAST 인증 CI/CD 변수 목록은 인증 변수를 참조하세요.


DAST CI/CD 변수 테이블은 Rake 작업 bundle exec rake gitlab:dast_variables:compile_docs에 의해 생성됩니다. lib/gitlab/security/dast_variables.rb에 정의된 변수 메타데이터를 사용합니다.


대상 웹사이트 업데이트#


CI/CD 변수 DAST_TARGET_URL을 사용하여 정의된 대상 웹사이트는 DAST가 애플리케이션 크롤링을 시작하는 URL입니다.


인증된 스캔에서 최상의 크롤링 결과를 얻으려면 대상 웹사이트가 사용자가 인증된 후에만 접근 가능한 URL이어야 합니다.
보통 이는 사용자가 로그인한 후 도달하는 페이지의 URL입니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/dashboard/welcome"
    DAST_AUTH_URL: "https://example.com/login"



HTTP 인증 구성#


Basic 인증과 같은 HTTP 인증 체계를 사용하려면 DAST_AUTH_TYPE 값을 basic-digest로 설정할 수 있습니다.
Negotiate 또는 NTLM과 같은 다른 체계도 작동할 수 있지만 현재 자동화된 테스트 커버리지 부족으로 인해 공식적으로 지원되지 않습니다.


구성에는 DAST 작업에 대해 CI/CD 변수 DAST_AUTH_TYPE, DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD가 정의되어야 합니다. 고유한 로그인 URL이 없는 경우 DAST_AUTH_URL을 DAST_TARGET_URL과 동일한 URL로 설정합니다.


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_TYPE: "basic-digest"
    DAST_AUTH_URL: "https://example.com"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


단일 단계 로그인 양식 구성#


단일 단계 로그인 양식에는 모든 로그인 양식 요소가 단일 페이지에 있습니다.
구성에는 DAST 작업에 대해 CI/CD 변수 DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD, DAST_AUTH_PASSWORD_FIELD 및 DAST_AUTH_SUBMIT_FIELD가 정의되어야 합니다.


작업 정의 YAML에서 URL과 필드 선택자를 설정해야 합니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


다단계 로그인 양식 구성#


다단계 로그인 양식에는 두 페이지가 있습니다. 첫 번째 페이지에는 사용자 이름과 다음 제출 버튼이 있는 양식이 있습니다.
사용자 이름이 유효하면 이후 페이지의 두 번째 양식에는 비밀번호와 양식 제출 버튼이 있습니다.


구성에는 DAST 작업에 대해 다음 CI/CD 변수가 정의되어야 합니다:


    

  • DAST_AUTH_URL
    • 

  • DAST_AUTH_USERNAME
    • 

  • DAST_AUTH_USERNAME_FIELD
    • 

  • DAST_AUTH_FIRST_SUBMIT_FIELD
    • 

  • DAST_AUTH_PASSWORD
    • 

  • DAST_AUTH_PASSWORD_FIELD
    • 

  • DAST_AUTH_SUBMIT_FIELD.
    • 



작업 정의 YAML에서 URL과 필드 선택자를 설정해야 합니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_FIRST_SUBMIT_FIELD: "css:button[name=next]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_USERNAME 및 DAST_AUTH_PASSWORD를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


시간 기반 일회용 비밀번호(TOTP) 구성#


TOTP 구성에는 DAST 작업에 대해 다음 CI/CD 변수가 정의되어야 합니다:


    

  • DAST_AUTH_OTP_FIELD
    • 

  • DAST_AUTH_OTP_KEY
    • 



비밀번호가 제출된 후 TOTP 토큰이 자체 양식으로 제출되는 경우 이 변수도 정의해야 합니다:


    

  • DAST_AUTH_OTP_SUBMIT_FIELD
    • 



_FIELD 선택자 변수는 작업 정의 YAML에서 정의할 수 있습니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
    DAST_AUTH_OTP_FIELD: "name:otp"
    DAST_AUTH_OTP_SUBMIT_FIELD: "css:input[type=submit]"



보안 위험이 있을 수 있으므로 YAML 작업 정의 파일에 DAST_AUTH_OTP_KEY를 정의하지 마세요. 대신 GitLab UI를 사용하여 마스킹된 CI/CD 변수로 생성합니다.
자세한 내용은 사용자 지정 CI/CD 변수를 참조하세요.


Single Sign-On (SSO) 구성#


사용자가 애플리케이션에 로그인할 수 있다면 대부분의 경우 DAST도 로그인할 수 있습니다.
SSO를 사용하는 애플리케이션도 마찬가지입니다. SSO 솔루션을 사용하는 애플리케이션은 단일 단계 또는 다단계 로그인 양식 구성 가이드를 사용하여 DAST 인증을 구성해야 합니다.


DAST는 사용자가 로그인하기 위해 외부 ID 공급자 사이트로 리디렉션되는 인증 프로세스를 지원합니다.
DAST 인증의 알려진 문제를 확인하여 SSO 인증 프로세스가 지원되는지 확인합니다.


Windows 통합 인증(Kerberos) 구성#


Windows 통합 인증(Kerberos)은 Windows 도메인 내에서 호스팅되는 LOB(Line of Business) 애플리케이션에 대한 일반적인 인증 메커니즘입니다. 사용자의 컴퓨터 로그인을 사용하여 자동 인증을 제공합니다.


이 인증 양식을 구성하려면 다음 단계를 수행합니다:


    

  1. IT/운영 팀의 도움을 받아 필요한 정보를 수집합니다.
    2. 

  2. .gitlab-ci.yml 파일에서 dast 작업 정의를 생성하거나 업데이트합니다.
    3. 

  3. 수집된 정보를 사용하여 예시 krb5.conf 파일을 채웁니다.
    4. 

  4. 필요한 작업 변수를 설정합니다.
    5. 

  5. 프로젝트 설정 페이지를 사용하여 필요한 시크릿 변수를 설정합니다.
    6. 

  6. 인증이 작동하는지 테스트하고 확인합니다.
    7. 



IT/운영 부서의 도움을 받아 다음 정보를 수집합니다:


    

  • Windows 도메인 또는 Kerberos Realm 이름(이름에 마침표가 있어야 합니다, 예: EXAMPLE.COM)
    • 

  • Windows/Kerberos 도메인 컨트롤러의 호스트 이름
    • 

  • Kerberos의 경우 인증 서버 이름. Windows 도메인의 경우 도메인 컨트롤러입니다.
    • 



krb5.conf 파일 생성:


[libdefaults]
  # Realm is another name for domain name
  default_realm = EXAMPLE.COM
  # These settings are not needed for Windows Domains
  # they support other Kerberos implementations
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    # Domain controller or KDC
    kdc = kdc.example.com
    # Domain controller or admin server
    admin_server = kdc.example.com
  }
[domain_realm]
  # Mapping DNS domains to realms/Windows domain
  # DNS domains provided by DAST_AUTH_NEGOTIATE_DELEGATION
  # should also be represented here (but without the wildcard)
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM



이 구성은 DAST_AUTH_NEGOTIATE_DELEGATION 변수를 사용합니다.
이 변수는 통합 인증을 허용하는 데 필요한 다음 Chromium 정책을 설정합니다:



이 변수의 설정은 Windows 도메인 또는 Kerberos 영역과 연결된 DNS 도메인입니다.
다음 형식으로 제공해야 합니다:


    

  • 소문자와 대문자 모두.
    • 

  • 와일드카드 패턴과 도메인 이름만.
    • 



예에서 Windows 도메인은 EXAMPLE.COM이고 DNS 도메인은 example.com입니다.
이는 DAST_AUTH_NEGOTIATE_DELEGATION에 대해 *.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM 값을 제공합니다.


작업 정의로 모두 결합합니다:


# This job will extend the dast job defined in
# the DAST template which must also be included.
dast:
  image:
    name: "$SECURE_ANALYZERS_PREFIX/dast:$DAST_VERSION$DAST_IMAGE_SUFFIX"
    docker:
      user: root
  variables:
    DAST_TARGET_URL: https://target.example.com
    DAST_AUTH_URL: https://target.example.com
    DAST_AUTH_TYPE: basic-digest
    DAST_AUTH_NEGOTIATE_DELEGATION: '*.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM'
    # Not shown -- DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD set via Settings -> CI -> Variables
  before_script:
    - KRB5_CONF='
[libdefaults]
  default_realm = EXAMPLE.COM
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    kdc = ad1.example.com
    admin_server = ad1.example.com
  }
[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
'
    - cat "$KRB5_CONF" > /etc/krb5.conf
    - echo '$DAST_AUTH_PASSWORD' | kinit $DAST_AUTH_USERNAME
    - klist



예상 출력:


작업 콘솔 출력에는 before 스크립트의 출력이 포함됩니다. 인증이 성공한 경우 다음과 유사하게 보입니다. 인증이 실패하면 스캔을 실행하지 않고 작업이 실패해야 합니다.


Password for mike@EXAMPLE.COM:
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mike@EXAMPLE.COM

Valid starting       Expires              Service principal
11/11/2024 21:50:50  11/12/2024 07:50:50  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 11/12/2024 21:50:50



DAST 스캐너도 다음을 출력하여 성공을 나타냅니다:


2024-11-08T17:03:09.226 INF AUTH  attempting to authenticate find_auth_fields="basic-digest"
2024-11-08T17:03:09.226 INF AUTH  loading login page LoginURL="https://target.example.com"
2024-11-08T17:03:10.619 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (auto-detected)"
2024-11-08T17:03:10.619 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 want="HTTP status code < 400" url="https://target.example.com/"
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, did not detect a login form want="no login form found (auto-detected)"
2024-11-08T17:03:10.623 INF AUTH  authentication token cookies names=""
2024-11-08T17:03:10.623 INF AUTH  authentication token storage events keys=""
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, basic authentication detected want="has authentication token"
2024-11-08T17:03:11.230 INF AUTH  login attempt succeeded



로그인 양식으로 클릭하여 이동#


DAST_AUTH_URL에서 클릭할 요소의 경로를 제공하려면 DAST_AUTH_BEFORE_LOGIN_ACTIONS를 정의하여 DAST가 로그인 양식에 액세스할 수 있도록 합니다. 이 방법은 팝업(모달) 창에 로그인 양식을 표시하거나 로그인 양식에 고유한 URL이 없는 애플리케이션에 적합합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_BEFORE_LOGIN_ACTIONS: "css:.navigation-menu,css:.login-menu-item"



로그인 양식 제출 후 추가 작업 수행#


인증 세부 정보가 기록될 때 로그인 양식을 제출한 후, 확인 전에 수행할 작업 시퀀스를 제공하려면 DAST_AUTH_AFTER_LOGIN_ACTIONS를 정의합니다.
이는 "로그인 상태 유지" 대화 상자를 건너뛰는 데 사용할 수 있습니다.






작업
형식






요소 클릭
click(on=<selector>)




드롭다운에서 옵션 선택
select(option=<selector>)






작업은 쉼표로 구분됩니다. 선택자에 대한 정보는 요소의 선택자 찾기를 참조하세요.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_AFTER_LOGIN_ACTIONS: "select(option=id:accept-yes),click(on=id:continue-button)"



로그아웃 URL 제외#


DAST가 인증된 스캔을 실행하는 동안 로그아웃 URL을 크롤링하면 사용자가 로그아웃되어 나머지 스캔이 인증되지 않은 상태가 됩니다.
따라서 CI/CD 변수 DAST_SCOPE_EXCLUDE_URLS를 사용하여 로그아웃 URL을 제외하는 것이 좋습니다. DAST는 제외된 URL에 액세스하지 않으므로 사용자가 로그인 상태를 유지합니다.


제공된 URL은 절대 URL이거나 DAST_TARGET_URL의 기본 경로에 상대적인 URL 경로의 정규식일 수 있습니다. 예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/welcome/home"
    DAST_SCOPE_EXCLUDE_URLS: "https://example.com/logout,/user/.*/logout"



요소의 선택자 찾기#


선택자는 CI/CD 변수에서 브라우저의 페이지에 표시된 요소의 위치를 지정하는 데 사용됩니다.
선택자의 형식은 유형:검색 문자열입니다. DAST는 유형을 기반으로 검색 문자열을 사용하여 선택자를 검색합니다.






선택자 유형
예시
설명






css
css:.password-field
제공된 CSS 선택자를 가진 HTML 요소를 검색합니다. 성능상의 이유로 선택자는 가능한 한 구체적이어야 합니다.




id
id:element
제공된 요소 ID를 가진 HTML 요소를 검색합니다.




name
name:element
제공된 요소 이름을 가진 HTML 요소를 검색합니다.




xpath
xpath://input[@id="my-button"]/a
제공된 XPath를 가진 HTML 요소를 검색합니다. XPath 검색은 다른 검색보다 성능이 낮을 것으로 예상됩니다.






Google Chrome으로 선택자 찾기#


Chrome DevTools 요소 선택자 도구는 선택자를 찾는 효과적인 방법입니다.


    

  1. Chrome을 열고 선택자를 찾을 페이지(예: 사이트의 로그인 페이지)로 이동합니다.
    2. 

  2. macOS에서는 키보드 단축키 Command+Shift+C를, Windows 또는 Linux에서는 Control+Shift+C를 사용하여 Chrome DevTools의 Elements 탭을 엽니다.
    3. 

  3. 페이지에서 요소를 선택하여 검사 도구를 선택합니다.
search-elements
    4. 

  4. 선택자를 알고 싶은 페이지의 필드를 선택합니다.
    5. 

  5. 도구가 활성화된 후 세부 정보를 보고 싶은 필드를 강조 표시합니다.
highlight
    6. 

  6. 강조 표시되면 선택자의 좋은 후보가 될 수 있는 속성을 포함한 요소의 세부 정보를 볼 수 있습니다.
    7. 



이 예에서 id="user_login"이 좋은 후보로 보입니다. DAST_AUTH_USERNAME_FIELD: "id:user_login"으로 설정하여 DAST 사용자 이름 필드의 선택자로 사용할 수 있습니다.


올바른 선택자 선택#


선택자를 신중하게 선택하면 애플리케이션이 변경되어도 스캔이 탄력적으로 작동합니다.


선택 우선순위에 따라 다음을 선택자로 선택해야 합니다:


    

  • id 필드. 이 필드는 일반적으로 페이지에서 고유하며 거의 변경되지 않습니다.
    • 

  • name 필드. 이 필드는 일반적으로 페이지에서 고유하며 거의 변경되지 않습니다.
    • 

  • 사용자 이름 필드의 username 클래스에 대한 선택자 "css:.username"과 같이 필드에 특정한 class 값.
    • 

  • 사용자 이름 필드에 data-username 필드가 어떤 값을 가질 때 선택자 "css:[data-username]"과 같이 필드별 데이터 속성의 존재.
    • 

  • username 클래스를 가진 요소가 여러 개 있지만 login-form 클래스를 가진 요소 안에 하나만 중첩된 경우 선택자 "css:.login-form .username"과 같이 여러 class 계층 값.
    • 



특정 필드를 찾기 위해 선택자를 사용할 때 다음 항목을 검색하지 않아야 합니다:


    

  • 동적으로 생성되는 id, name, attribute, class 또는 value.
    • 

  • column-10 및 dark-grey와 같은 일반적인 클래스 이름.
    • 

  • 다른 선택자 검색보다 성능이 낮은 XPath 검색.
    • 

  • css:* 및 xpath://*로 시작하는 범위 없는 검색.
    • 



인증 성공 확인#


DAST가 로그인 양식을 제출한 후 인증이 성공했는지 확인하는 검증 프로세스가 수행됩니다. 인증에 실패하면 오류와 함께 스캔이 중지됩니다.


로그인 양식 제출 후 다음과 같은 경우 인증이 실패한 것으로 판단됩니다:


    

  • 로그인 제출 HTTP 응답에 400 또는 500 시리즈 상태 코드가 있습니다.
    • 

  • 어떤 확인 검사가 실패합니다.
    • 

  • 인증 프로세스 중에 충분히 무작위 값을 가진 인증 토큰이 설정되지 않습니다.
    • 



확인 검사#


확인 검사는 인증이 완료되면 브라우저 상태를 확인하여 인증이 성공했는지 추가로 확인합니다.


확인 검사가 구성되지 않은 경우 DAST는 로그인 양식의 부재를 테스트합니다.


URL을 기반으로 확인#


로그인 양식이 성공적으로 제출된 후 브라우저 탭에 표시되는 URL로 DAST_AUTH_SUCCESS_IF_AT_URL을 정의합니다.


DAST는 인증 후 브라우저의 URL과 확인 URL을 비교합니다.
동일하지 않으면 인증이 실패합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_AT_URL: "https://example.com/user/welcome"



요소의 존재를 기반으로 확인#


로그인 양식이 성공적으로 제출된 후 표시되는 페이지에서 하나 이상의 요소를 찾는 선택자로 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND를 정의합니다. 요소가 발견되지 않으면 인증이 실패합니다.
로그인이 실패할 때 표시되는 페이지에서 선택자를 검색하면 결과가 없어야 합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND: "css:.welcome-user"



로그인 양식의 부재를 기반으로 확인#


DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM을 "true"로 정의하여 로그인 양식이 성공적으로 제출된 후 표시되는 페이지에서 DAST가 로그인 양식을 검색해야 함을 나타냅니다. 로그인 후 로그인 양식이 여전히 있으면 인증이 실패합니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM: "true"



인증 토큰#


DAST는 인증 프로세스 중에 설정된 인증 토큰을 기록합니다.
사용자가 스캔 전반에 걸쳐 로그인 상태를 유지할 수 있도록 DAST가 새 브라우저를 열 때 인증 토큰이 로드됩니다.


토큰을 기록하기 위해 DAST는 인증 프로세스 전에 애플리케이션에서 설정한 쿠키, 로컬 스토리지 및 세션 스토리지 값의 스냅샷을 찍습니다. DAST는 인증 후에도 동일한 작업을 수행하고 차이를 사용하여 인증 프로세스에 의해 생성된 것을 확인합니다.


DAST는 충분히 "무작위" 값으로 설정된 쿠키, 로컬 스토리지 및 세션 스토리지 값을 인증 토큰으로 간주합니다.
예를 들어 sessionID=HVxzpS8GzMlPAc2e39uyIVzwACIuGe0H는 인증 토큰으로 간주되지만 ab_testing_group=A1은 그렇지 않습니다.


CI/CD 변수 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 쿠키의 이름을 지정하고 DAST에서 사용하는 무작위성 검사를 우회할 수 있습니다.
이렇게 하면 인증 프로세스가 더 강력해질 뿐만 아니라 인증 토큰을 검사하는 검사의 취약성 검사 정확도도 향상될 수 있습니다.


예를 들어:


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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_COOKIE_NAMES: "sessionID,refreshToken"



알려진 문제#


    

  • 인증 흐름에 CAPTCHA가 포함된 경우 DAST는 CAPTCHA를 우회할 수 없습니다.
테스트 환경에서 스캔 중인 애플리케이션의 구성된 사용자에 대해 이를 비활성화합니다.
    • 

  • DAST는 SMS 또는 생체 인식을 사용하여 일회용 비밀번호(OTP)로 인증할 수 없습니다.
테스트 환경에서 스캔 중인 애플리케이션의 구성된 사용자에 대해 이를 비활성화하거나 사용자의 MFA 유형을 TOTP로 변경합니다.
    • 

  • DAST는 로그인 중에 인증 토큰을 설정하지 않는 애플리케이션에 인증할 수 없습니다.
    • 

  • DAST는 사용자 이름, 비밀번호 및 선택적 TOTP보다 많은 텍스트 입력이 필요한 애플리케이션에 인증할 수 없습니다.
    • 



문제 해결#


로그는 인증 프로세스 중에 DAST가 무엇을 하고 무엇을 기대하는지에 대한 통찰력을 제공합니다. 자세한 정보는 인증 보고서를 구성하세요.


특정 오류 메시지나 상황에 대한 자세한 내용은 알려진 문제를 참조하세요.


브라우저 기반 분석기는 사용자를 인증하는 데 사용됩니다. 고급 문제 해결은 브라우저 기반 문제 해결을 참조하세요.


로그 읽기#


DAST CI/CD 작업의 콘솔 출력은 AUTH 로그 모듈을 사용하여 인증 프로세스에 대한 정보를 표시합니다.
예를 들어 다음 로그는 다단계 로그인 양식에 대한 실패한 인증을 보여줍니다.
로그인 후 홈 페이지가 표시되어야 하는데 대신 로그인 양식이 여전히 있었기 때문에 인증이 실패했습니다.


2022-11-16T13:43:02.000 INF AUTH  attempting to authenticate
2022-11-16T13:43:02.000 INF AUTH  loading login page LoginURL=https://example.com/login
2022-11-16T13:43:10.000 INF AUTH  multi-step authentication detected
2022-11-16T13:43:15.000 INF AUTH  verifying if user submit was successful true_when="HTTP status code < 400"
2022-11-16T13:43:15.000 INF AUTH  requirement is satisfied, no login HTTP message detected want="HTTP status code < 400"
2022-11-16T13:43:20.000 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-24T14:43:20.000 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 url=https://example.com/user/login?error=invalid%20credentials want="HTTP status code < 400"
2022-11-16T13:43:21.000 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-16T13:43:21.000 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"



인증 보고서 구성#


Warning


인증 보고서에는 로그인을 수행하는 데 사용된 자격 증명과 같은 민감한 정보가 포함될 수 있습니다.




인증 보고서는 인증 실패의 원인을 이해하는 데 도움이 되도록 CI/CD 작업 아티팩트로 저장될 수 있습니다.


보고서에는 로그인 프로세스 중에 수행된 단계, HTTP 요청 및 응답, DOM(Document Object Model) 및 스크린샷이 포함됩니다.


dast-auth-report


인증 디버그 보고서를 내보내는 예시 구성은 다음과 같을 수 있습니다:


dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_REPORT: "true"



알려진 문제#


로그인 양식을 찾을 수 없음#


DAST가 로그인 페이지를 로드할 때 로그인 양식을 찾지 못했습니다. 인증 URL을 로드할 수 없는 경우가 많습니다.
로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T12:44:02.838 INF AUTH  loading login page LoginURL=[authentication URL]
2022-12-07T12:44:11.119 FTL MAIN  authentication failed: login form not found



권장 조치:


    

  • 인증 보고서를 생성하여 HTTP 응답을 검사합니다.
    • 

  • 대상 애플리케이션 인증이 배포되고 실행 중인지 확인합니다.
    • 

  • DAST_AUTH_URL이 올바른지 확인합니다.
    • 

  • GitLab Runner가 DAST_AUTH_URL에 액세스할 수 있는지 확인합니다.
    • 

  • 사용된 경우 DAST_AUTH_BEFORE_LOGIN_ACTIONS가 유효한지 확인합니다.
    • 



스캔이 인증된 페이지를 크롤링하지 않음#


DAST가 인증 프로세스 중에 잘못된 인증 토큰을 캡처하면 스캔이 인증된 페이지를 크롤링할 수 없습니다. 쿠키 및 스토리지 인증 토큰의 이름이 로그에 기록됩니다. 예를 들어:


2022-11-24T14:42:31.492 INF AUTH  authentication token cookies names=["sessionID"]
2022-11-24T14:42:31.492 INF AUTH  authentication token storage events keys=["token"]



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 로그인이 예상대로 작동했는지 확인합니다.
    • 

  • 로그된 인증 토큰이 애플리케이션에서 사용하는 것인지 확인합니다.
    • 

  • 인증 토큰을 쿠키에 저장하는 경우 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 토큰 쿠키의 이름을 설정합니다.
    • 



선택자로 요소를 찾을 수 없음#


DAST가 사용자 이름, 비밀번호, 첫 번째 제출 버튼 또는 제출 버튼 요소를 찾지 못했습니다. 로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T13:14:11.545 FTL MAIN  authentication failed: unable to find elements with selector: css:#username



권장 조치:


    

  • 인증 보고서를 생성하여 Login page의 스크린샷을 사용하여 페이지가 올바르게 로드되었는지 확인합니다.
    • 

  • 브라우저에서 로그인 페이지를 로드하고 DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD_FIELD, DAST_AUTH_FIRST_SUBMIT_FIELD 및 DAST_AUTH_SUBMIT_FIELD에 구성된 선택자가 올바른지 확인합니다.
    • 



사용자 인증 실패#


DAST가 로그인 확인 검사 실패로 인해 인증에 실패했습니다. 로그에 다음과 같은 치명적 오류가 보고됩니다:


2022-12-07T06:39:49.483 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.484 INF AUTH  requirement is satisfied, HTTP login request returned status code 303 url=http://auth-manual:8090/login want="HTTP status code < 400"
2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.589 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"
2022-12-07T06:39:53.626 FTL MAIN  authentication failed: failed to authenticate user



권장 조치:


    

  • 로그에서 requirement is unsatisfied를 찾습니다. 적절한 오류에 대응합니다.
    • 



요건 미충족, 로그인 양식 발견됨#


애플리케이션은 일반적으로 사용자가 로그인하면 대시보드를 표시하고 사용자 이름이나 비밀번호가 잘못된 경우 오류 메시지와 함께 로그인 양식을 표시합니다.


이 오류는 DAST가 사용자를 인증한 후 표시된 페이지에서 로그인 양식을 감지하면 발생하여 로그인 시도가 실패했음을 나타냅니다.


2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"



권장 조치:


    

  • 사용된 사용자 이름과 비밀번호/인증 자격 증명이 올바른지 확인합니다.
    • 

  • 인증 보고서를 생성하고 Login submit에 대한 Request가 올바른지 확인합니다.
    • 

  • 인증 보고서 Login submit 요청 및 응답이 비어 있을 수 있습니다. 이는 HTML 양식을 제출할 때 전체 페이지 재로드를 일으키는 요청이 없을 때 발생합니다. 웹소켓이나 AJAX를 사용하여 로그인 양식을 제출할 때 발생합니다.
    • 

  • 사용자 인증 후 표시되는 페이지에 로그인 양식 선택자와 일치하는 요소가 실제로 있는 경우 DAST_AUTH_SUCCESS_IF_AT_URL 또는 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND를 구성하여 로그인 시도를 확인하는 다른 방법을 사용합니다.
    • 



요건 미충족, 선택자 결과 없음#


DAST가 사용자 로그인 후 표시된 페이지에서 DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND에 제공된 선택자와 일치하는 요소를 찾을 수 없습니다.


2022-12-07T06:39:33.239 INF AUTH  requirement is unsatisfied, searching DOM using selector returned no results want="has element css:[name=welcome]"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 예상 페이지가 표시되는지 확인합니다.
    • 

  • DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND 선택자가 올바른지 확인합니다.
    • 



요건 미충족, 브라우저가 URL에 없음#


DAST가 사용자 로그인 후 표시된 페이지의 URL이 DAST_AUTH_SUCCESS_IF_AT_URL에 따라 예상된 것과 다름을 감지했습니다.


2022-12-07T11:28:00.241 INF AUTH  requirement is unsatisfied, browser is not at URL browser_url="https://example.com/home" want="is at url https://example.com/user/dashboard"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 예상 페이지가 표시되는지 확인합니다.
    • 

  • DAST_AUTH_SUCCESS_IF_AT_URL이 올바른지 확인합니다.
    • 



요건 미충족, HTTP 로그인 요청 상태 코드#


로그인 양식을 로드하거나 양식을 제출할 때의 HTTP 응답이 400(클라이언트 오류) 또는 500(서버 오류) 상태 코드를 가졌습니다.


2022-12-07T06:39:53.626 INF AUTH  requirement is unsatisfied, HTTP login request returned status code 502 url="https://example.com/user/login" want="HTTP status code < 400"



    

  • 사용된 사용자 이름과 비밀번호/인증 자격 증명이 올바른지 확인합니다.
    • 

  • 인증 보고서를 생성하고 Login submit에 대한 Request가 올바른지 확인합니다.
    • 

  • 대상 애플리케이션이 예상대로 작동하는지 확인합니다.
    • 



요건 미충족, 인증 토큰 없음#


DAST가 인증 프로세스 중에 생성된 인증 토큰을 감지할 수 없었습니다.


2022-12-07T11:25:29.010 INF AUTH  authentication token cookies names=[]
2022-12-07T11:25:29.010 INF AUTH  authentication token storage events keys=[]
2022-12-07T11:25:29.010 INF AUTH  requirement is unsatisfied, no basic authentication, cookie or storage event authentication token detected want="has authentication token"



권장 조치:


    

  • 인증 보고서를 생성하고 Login submit의 스크린샷을 확인하여 로그인이 예상대로 작동했는지 확인합니다.
    • 

  • 브라우저의 개발자 도구를 사용하여 로그인하는 동안 생성된 쿠키 및 로컬/세션 스토리지 객체를 조사합니다. 충분히 무작위 값으로 생성된 인증 토큰이 있는지 확인합니다.
    • 

  • 인증 토큰을 쿠키에 저장하는 경우 DAST_AUTH_COOKIE_NAMES를 사용하여 인증 토큰 쿠키의 이름을 설정합니다.
    •