본문으로 건너뛰기

DAST 스캔

코드만 봐서는 발견할 수 없는 취약점도 있습니다. DAST(Dynamic Application Security Testing)는 실제로 실행 중인 애플리케이션에 HTTP 요청을 보내 취약점을 탐지하는 방법입니다. 마치 해커가 외부에서 공격하는 것처럼 애플리케이션을 테스트합니다.

DAST가 왜 필요한가요?

SAST는 코드를 분석하지만, 서버 설정 오류나 배포 환경의 문제는 발견하지 못합니다. 예를 들어 보안 헤더 누락, 쿠키 설정 오류, CORS 설정 문제 등은 애플리케이션이 실제로 실행되어야만 확인할 수 있습니다. DAST는 이러한 런타임 취약점을 찾아줍니다.

도메인 검사 탭

개요

  • 분석 대상: 실행 중인 웹 애플리케이션
  • 분석 시점: Operate 단계 (배포 후)
  • 분석 엔진: OWASP ZAP
  • 분석 방식: 실제 HTTP 요청을 보내 응답을 분석

DAST의 특징

장점

DAST만이 제공하는 고유한 장점들이 있습니다:

  • 실제 환경 테스트: 프로덕션과 동일한 환경에서 테스트하여 실제 위험을 파악
  • 설정 오류 탐지: 웹 서버, 프레임워크, 클라우드 설정의 보안 문제 발견
  • 인증 테스트: 로그인 우회, 세션 관리 취약점 등 인증 관련 문제 검증
  • 런타임 취약점: 코드만 봐서는 알 수 없는, 실행 중에만 나타나는 문제 탐지

SAST vs DAST: 언제 무엇을 사용할까요?

SAST

  • 분석 대상: 소스 코드
  • 분석 시점: 개발 중 (Source 단계)
  • 오탐율: 상대적으로 높음
  • 범위: 전체 코드베이스
  • 발견 가능한 문제: 코드 레벨 취약점
  • 장점: 개발 초기에 문제 발견

DAST

  • 분석 대상: 실행 중인 앱
  • 분석 시점: 배포 후 (Operate 단계)
  • 오탐율: 상대적으로 낮음
  • 범위: 접근 가능한 엔드포인트만
  • 발견 가능한 문제: 설정 오류, 런타임 취약점
  • 장점: 실제 환경의 문제 발견
두 가지 모두 사용하세요

SAST와 DAST는 상호 보완적입니다. SAST는 개발 단계에서, DAST는 배포 후에 실행하여 각각 다른 유형의 취약점을 커버하세요.


Step 1: DAST 스캔 시작하기

  1. [서비스 관리] 페이지로 이동합니다.
  2. 분석할 서비스를 선택합니다.
  3. Operate 단계를 클릭합니다.
  4. DAST 탭을 선택합니다.
  5. 스캔 시작 버튼을 클릭합니다.

Step 2: 스캔 대상 설정

2.1 대상 URL 입력

스캔할 애플리케이션의 URL을 입력합니다:

  • Target URL: 스캔 대상의 기본 URL입니다.
    • 예: https://api.company.com 또는 https://staging.myapp.com
  • Base Path: 스캔을 시작할 경로입니다 (선택사항)
    • 예: /api/v1 - API 서버라면 API 경로부터 시작

2.2 인증 설정 (선택)

로그인이 필요한 애플리케이션이라면 인증 정보를 설정하세요:

  • 없음: 인증 없이 공개 영역만 스캔
  • Basic Auth: HTTP Basic 인증 (사용자명/비밀번호)
  • Bearer Token: JWT 토큰 인증 (Authorization: Bearer 헤더)
  • Cookie: 세션 쿠키 (로그인 후 쿠키 값 입력)
인증된 스캔의 중요성

인증 없이 스캔하면 로그인 후에만 접근 가능한 페이지의 취약점은 발견할 수 없습니다. 중요한 기능이 로그인 뒤에 있다면 반드시 인증 정보를 설정하세요.


Step 3: 스캔 옵션 설정

3.1 스캔 유형 선택

목적에 맞는 스캔 유형을 선택하세요:

  • Baseline (패시브 스캔)

    • 소요 시간: 5-10분
    • 특징: 응답을 분석만 하고 공격적인 요청을 보내지 않음
    • 권장 환경: 개발 환경, CI 파이프라인
    • 탐지 가능: 보안 헤더 누락, 쿠키 설정 문제 등
  • Full (액티브 스캔)

    • 소요 시간: 30분 - 2시간
    • 특징: SQL Injection, XSS 등을 테스트하기 위해 악성 페이로드 전송
    • 권장 환경: 스테이징 환경
    • 탐지 가능: SQL Injection, XSS, CSRF 등 대부분의 취약점
  • API (API 전용 스캔)

    • 소요 시간: 15-30분
    • 특징: REST API 엔드포인트에 최적화된 스캔
    • 권장 환경: API 서버
    • 탐지 가능: API 인증 우회, 파라미터 변조 등

3.2 스캔 범위 설정

불필요한 스캔을 줄이고 효율성을 높이세요:

  • 깊이: URL 크롤링 깊이를 제한합니다 (예: 3단계까지만)
  • 범위: 특정 경로로 스캔 범위를 제한합니다 (예: /api/*만 스캔)
  • 제외: 스캔에서 제외할 경로를 지정합니다 (예: /admin/* 제외)
프로덕션 환경에서 Full 스캔 주의

Full 스캔은 SQL Injection 테스트 등을 위해 실제 공격 페이로드를 전송합니다. 프로덕션 환경에서는 다음 문제가 발생할 수 있습니다:

  • 대량의 요청: 서버 부하 증가
  • 데이터 변경: 악성 페이로드가 데이터를 변경할 수 있음
  • 서비스 영향: 일시적인 오류나 성능 저하 가능

프로덕션에서는 Baseline 스캔만 실행하거나, Full 스캔은 스테이징 환경에서 실행하세요.


Step 4: 스캔 실행

4.1 스캔 진행

스캔이 시작되면 다음과 같은 단계로 진행됩니다:

[1/5] Initializing ZAP...           ← OWASP ZAP 초기화
[2/5] Crawling target site... ← 대상 사이트 크롤링
→ Found 45 URLs ← 45개 URL 발견
→ Found 12 forms ← 12개 폼 발견
[3/5] Running passive scan... ← 패시브 스캔 실행
→ Analyzing headers... ← 응답 헤더 분석
→ Checking cookies... ← 쿠키 설정 확인
[4/5] Running active scan... ← 액티브 스캔 실행 (Full만)
→ Testing SQL injection... ← SQL Injection 테스트
→ Testing XSS... ← XSS 테스트
→ Testing CSRF... ← CSRF 테스트
[5/5] Generating report... ← 보고서 생성
Scan completed! ← 완료

4.2 스캔 상태

  • Idle: 스캔 대기 중
  • Crawling: URL 수집 중 - 대상 사이트의 모든 페이지를 탐색
  • Analyzing: 취약점 분석 중 - 패시브/액티브 스캔 진행
  • Completed: 스캔 완료 - 결과 확인 가능
  • Failed: 스캔 실패 - 오류 메시지 확인 필요

Step 5: 결과 확인

5.1 결과 요약

스캔이 완료되면 다음 정보를 한눈에 확인할 수 있습니다:

  • 총 알림: 탐지된 취약점 및 이슈의 총 개수
  • 위험도 분포: High/Medium/Low/Info별 분류
  • 스캔된 URL: 테스트된 URL 개수
  • 요청 수: 전송된 HTTP 요청 수

5.2 취약점 상세

각 취약점을 클릭하면 다음 정보를 확인할 수 있습니다:

  • Alert Type: 취약점 유형 (예: SQL Injection, XSS)
  • Risk Level: 위험도 (High/Medium/Low/Informational)
  • URL: 취약점이 발견된 URL
  • Parameter: 취약한 파라미터 이름
  • Evidence: 취약점의 증거 (요청/응답 내용)
  • Solution: 권장 해결 방법
  • Reference: OWASP, CWE 등 참조 링크
증거(Evidence) 활용하기

Evidence에는 실제 요청과 응답이 포함되어 있습니다. 이를 통해 취약점을 재현하고 수정 후 검증할 수 있습니다. 개발자에게 취약점을 전달할 때 Evidence를 함께 공유하면 이해가 빠릅니다.


주요 탐지 취약점

인젝션 취약점

외부 입력이 코드나 쿼리로 해석되는 취약점입니다.

  • SQL Injection (High): 사용자 입력이 SQL 쿼리에 삽입되어 데이터베이스 조작 가능
  • OS Command Injection (High): 사용자 입력이 시스템 명령어로 실행됨
  • LDAP Injection (High): 사용자 입력이 LDAP 쿼리에 삽입됨

XSS (Cross-Site Scripting)

악성 스크립트가 웹 페이지에 삽입되는 취약점입니다.

  • Reflected XSS (Medium): URL 파라미터의 값이 그대로 페이지에 출력됨
  • Stored XSS (High): 악성 스크립트가 서버에 저장되어 다른 사용자에게 표시됨
  • DOM-based XSS (Medium): 클라이언트 측 JavaScript에서 발생하는 XSS

설정 오류

서버나 애플리케이션 설정의 보안 문제입니다.

  • Missing Security Headers (Low-Medium): 보안 헤더(CSP, X-Frame-Options 등)가 누락되었습니다. 웹 서버 설정에서 보안 헤더를 추가하세요.
  • Cookie Flags (Medium): Secure/HttpOnly 플래그가 미설정되었습니다. 쿠키 생성 시 플래그를 설정하세요.
  • CORS Misconfiguration (Medium): 허용되지 않아야 할 출처에서 접근이 가능합니다. CORS 정책을 검토하고 수정하세요.
  • Directory Listing (Low): 디렉토리 목록이 외부에 노출됩니다. 웹 서버 설정에서 디렉토리 리스팅을 비활성화하세요.

인증/세션 취약점

로그인 및 세션 관리와 관련된 취약점입니다.

  • Broken Authentication (High): 인증을 우회하여 다른 사용자로 접근할 수 있습니다. 인증 로직을 검토하고 수정하세요.
  • Session Fixation (High): 공격자가 세션 ID를 고정하여 계정을 탈취할 수 있습니다. 로그인 시 세션 ID를 재생성하세요.
  • CSRF (Medium): 사용자 모르게 악의적인 요청이 실행됩니다. CSRF 토큰을 구현하세요.

자동 스캔 설정

배포 후 자동 스캔

배포가 완료될 때마다 자동으로 DAST 스캔을 실행할 수 있습니다.

  1. Auto CI 설정에서 DAST를 활성화합니다.
  2. 스캔 유형과 대상 URL을 설정합니다.
  3. 배포 완료 후 자동으로 스캔이 실행됩니다.
  4. 취약점 발견 시 알림을 받습니다.

스케줄 스캔

정기적인 보안 점검을 위해 스케줄 스캔을 설정하세요:

  • Daily (매일): 개발 환경에서 빈번한 변경 사항 점검
  • Weekly (매주): 스테이징 환경에서 통합 테스트와 함께 실행
  • Monthly (매월): 프로덕션 환경에서 정기 보안 점검
스케줄 스캔 시간 설정

스캔은 서버에 부하를 줄 수 있으므로, 사용량이 적은 시간(새벽, 주말 등)에 스케줄을 설정하세요.


문제 해결

스캔 실패

  • URL 접근 불가: 대상 URL이 KIWI 서버에서 접근 가능한지 확인하세요. 방화벽이나 VPN 설정을 확인하세요.

  • 인증 실패: 인증 정보가 올바른지 확인하세요. 토큰이 만료되었거나, 세션이 유효하지 않을 수 있습니다.

  • 타임아웃: 대상 사이트가 너무 크거나 응답이 느린 경우입니다. 스캔 범위를 축소하거나, 특정 경로만 스캔하세요.

  • SSL 오류: 자체 서명 인증서를 사용하는 경우 SSL 검증 옵션을 비활성화하세요.

오탐(False Positive) 처리

DAST도 때때로 실제로는 취약하지 않은 것을 취약점으로 보고할 수 있습니다.

  • False Positive 표시: 확인된 오탐은 "False Positive"로 표시하여 다음 스캔에서 제외합니다.

  • 규칙 조정: 특정 규칙이 너무 많은 오탐을 발생시키면 해당 규칙을 비활성화합니다.

  • 컨텍스트 추가: 인증 정보나 세션 정보를 제공하면 더 정확한 결과를 얻을 수 있습니다.

오탐 관리의 중요성

오탐이 너무 많으면 보안팀의 피로도가 높아지고 진짜 취약점을 놓칠 수 있습니다. 확인된 오탐은 적극적으로 표시하여 다음 스캔에서 제외하세요.


관련 가이드