본문으로 건너뛰기
중급22

OWASP ZAP과 Burp Suite로 DAST 실행하기

레슨 6에서 개념으로 배운 DAST를 실제 도구로 실행해본다. 자동 스캔이 무엇을 하는지, 그리고 그 결과를 QA가 왜 그대로 믿으면 안 되는지 익힌다.

  • #OWASPZAP
  • #BurpSuite
  • #DAST
  • #보안스캐너

개념

레슨 6의 DAST, 실제로는 이렇게 생겼다

레슨 6에서 DAST(Dynamic Application Security Testing)를 "실제로 애플리케이션을 실행한 상태에서, 외부에서 공격하듯 요청을 보내며 취약점을 찾는 것"이라고 배웠다. OWASP ZAPBurp Suite는 이 개념을 실제로 실행하는 대표적인 두 도구다.

프록시로 트래픽을 가로챈다는 점에서 익숙하다

모듈 9(레슨 10)에서 Charles로 네트워크 트래픽을 가로채는 법을 배웠다. ZAP과 Burp Suite도 같은 프록시 방식으로 동작한다 — 브라우저의 모든 요청이 이 도구를 거쳐가게 설정하면, 도구가 그 요청·응답을 기록하고 분석한다. Charles가 "디버깅"이 목적이었다면, ZAP·Burp Suite는 그 트래픽을 의도적으로 조작해 취약점을 찾아내는 것이 목적이라는 점이 다르다.

Charles(모듈 9): 요청을 관찰하고, 필요하면 조작해 화면 반응을 확인
ZAP/Burp Suite: 요청을 자동으로 변형해 대량으로 반복 전송하며,
                취약점 신호가 나오는지 자동으로 탐지

자동 스캔이 하는 일

ZAP의 "Active Scan"을 예로 들면, 도구가 사람 대신 다음을 자동으로 반복한다.

1. 페이지의 모든 입력 필드와 파라미터를 자동으로 찾아냄
2. 각 필드에 레슨 10에서 손으로 시도했던 것과 같은 종류의
   테스트 값(' OR '1'='1, <script>alert(1)</script> 등)을
   자동으로 대입
3. 응답을 분석해 에러 메시지, 비정상적인 응답 패턴이 나오는지 확인
4. 의심되는 항목을 위험도별로 정리해 리포트로 제시

레슨 10에서 사람이 손으로 한 땀 한 땀 시도했던 것을, 이 도구는 수백~수천 개의 입력 조합에 대해 자동으로, 훨씬 빠르게 반복한다. 이건 모듈 1(레슨 5)에서 배운 "조합 폭발"을 사람이 아니라 도구의 힘으로 다루는 방식이기도 하다.

Burp Suite와 ZAP — 무엇이 다른가

OWASP ZAPBurp Suite
라이선스완전 무료(오픈소스)무료판(Community)은 기능 제한, 유료판(Professional)이 실무 표준
진입 장벽상대적으로 쉬움, 입문용으로 많이 추천됨기능이 더 강력하지만 학습 곡선이 있음
확장성플러그인으로 확장 가능확장 기능(BApp Store)이 더 풍부하고 전문 침투 테스터가 많이 씀

실무에서는 예산과 팀의 전문성 수준에 따라 선택이 갈린다 — 이건 레슨 3(SoapUI 등)에서 반복해온 "도구는 우열이 아니라 상황의 문제"라는 원칙과 같다.

자동 스캔 결과를 그대로 믿으면 안 되는 이유

레슨 6에서 "SAST 결과의 모든 경고를 실제 취약점으로 단정하지 말라"고 배웠다. DAST 스캐너도 마찬가지다 — 자동 스캔은 의심되는 패턴을 찾아낼 뿐, 그게 실제로 악용 가능한 진짜 취약점인지는 사람이 확인해야 한다.

스캐너 보고: "이 파라미터에서 SQL Injection 가능성이 의심됩니다"
 
QA가 확인할 것:
- 레슨 10에서 배운 방식으로 실제로 재현되는가?
- 재현된다면 어떤 데이터까지 노출/조작 가능한가?
- 재현이 안 된다면 오탐(false positive)으로 분류하고 근거를 남긴다

이 확인 없이 스캐너 결과를 그대로 개발팀에 던지면, 오탐이 섞인 채로 전달되어 "이거 확인해보니 별거 아니던데요"라는 반응이 반복되고, 다음번 진짜 위험한 보고까지 신뢰를 잃게 된다 — 모듈 1(레슨 2)에서 배운, 잘못된 확신이 신뢰를 깎는다는 원칙과 같다.

실무에서 왜 필요한가

전담 보안팀이 없는 조직에서, QA가 릴리스 전 ZAP으로 자동 스캔을 한 번 돌려보는 것만으로도 명백한 보안 구멍(예: 관리자 페이지가 인증 없이 열려 있음)을 출시 전에 잡아낼 수 있다. 다만 이 레슨의 핵심은 도구 사용법 자체보다 **"스캐너는 후보를 찾아줄 뿐, 최종 판단은 레슨 10에서 배운 수동 확인으로 검증해야 한다"**는 태도다. 자동화와 수동 확인이 함께 있어야 신뢰할 수 있는 결과가 나온다.

실습 과제

과제 1 — 스캔 결과 검증 절차 설계하기 (12분)

"ZAP 자동 스캔에서 로그인 페이지의 아이디 입력란에 SQL Injection 의심 항목이 보고됐다"는 상황에서, 이걸 실제 취약점인지 확인하기 위해 어떤 순서로 검증할지(모듈 16 레슨 10을 참고해) 단계별로 적는다.

과제 2 — 오탐 판단 연습 (10분)

ZAP이 "이 페이지는 클릭재킹(Clickjacking)에 취약할 수 있습니다"를 보고했는데, 실제로 그 페이지는 로그인이 필요한 내부 관리자 페이지라 외부에서 직접 접근할 수 없다는 걸 알게 됐다. 이 발견을 오탐으로 분류할지, 그래도 리포트할지 판단하고 이유를 적는다.

해설 보기

정답이 하나로 정해지진 않지만, 핵심은 "공격 가능한 경로가 실제로 있는가"를 함께 따져야 한다는 것이다. 로그인이 필요한 내부 페이지라면 위험도는 훨씬 낮아지지만, "완전히 무시해도 된다"는 결론으로 바로 가기보다는 "내부 계정이 탈취된 경우엔 여전히 위험할 수 있다"처럼 낮은 우선순위로 재분류해 근거와 함께 남기는 것이 더 안전한 태도다. 오탐이라고 완전히 지워버리면, 나중에 상황이 바뀌었을 때(예: 그 페이지가 실수로 공개 접근 가능해짐) 그 기록을 다시 찾을 수 없게 된다.

자가 체크리스트

  • ZAP·Burp Suite가 레슨 6의 DAST 개념을 어떻게 실제로 구현하는지 설명할 수 있다
  • 이 도구들이 모듈 9의 Charles와 같은 프록시 방식이지만 목적이 다르다는 것을 설명할 수 있다
  • 자동 스캔이 사람의 수동 SQL Injection 시도(레슨 10)를 대량·자동으로 반복하는 것임을 이해한다
  • ZAP과 Burp Suite의 차이(라이선스, 진입 장벽)를 설명할 수 있다
  • 스캐너 결과를 왜 그대로 믿으면 안 되는지, 검증 없이 전달했을 때 생기는 문제를 설명할 수 있다

흔한 실수

  • 스캐너가 보고한 모든 항목을 검증 없이 그대로 개발팀에 전달한다. 오탐이 섞여 있으면 다음 보고의 신뢰도까지 깎인다.
  • 스캐너 결과를 100% 믿거나, 반대로 전부 무시한다. 둘 다 극단적이다 — 각 항목을 실제 재현 가능성과 위험도로 판단해야 한다.
  • 한 번 스캔하고 다시 안 돌린다. 코드가 계속 바뀌므로, 정기적 또는 배포 전마다 스캔하는 것이 안전망으로서 의미가 있다.
  • 운영 환경에 자동 스캔을 그대로 돌린다. 대량의 자동 요청이 실제 서비스에 부하를 주거나 실제 데이터를 훼손할 수 있다 — 반드시 테스트/스테이징 환경(모듈 7 레슨 3)에서 실행한다.

참고 자료