버그바운티는 기업이 공식적으로 허용한 범위 안에서 자사 서비스의 취약점을 찾아 신고하면 보상을 주는 프로그램이다. 무단으로 아무 서비스나 공격하는 것과는 명확히 다르다 — 반드시 프로그램이 명시한 스코프(scope)와 룰(rules of engagement) 안에서만 테스트해야 하고, 이걸 벗어나면 정당한 보안 리서치가 아니라 그냥 불법 침해가 된다.
시작하기 전에: 스코프와 룰 읽기
플랫폼(HackerOne, Bugcrowd, 국내는 KISA 취약점 신고포상제나 기업 자체 프로그램 등)에 올라온 프로그램마다 다음이 명시되어 있다.
- In-scope / Out-of-scope 자산: 테스트해도 되는 도메인/앱과, 절대 건드리면 안 되는 것(예: 제3자 서비스, 특정 서브도메인)
- 금지된 테스트 유형: DoS 유발 테스트, 자동화 스캐너의 무차별 대입, 소셜 엔지니어링(피싱) 등은 대부분 명시적으로 금지
- 보상 대상 취약점 등급: 어떤 심각도부터 보상하는지, 중복 신고 처리 기준
이걸 안 읽고 시작하면 아무리 좋은 취약점을 찾아도 "Out of scope"로 반려되거나, 최악의 경우 룰 위반으로 프로그램에서 영구 제외될 수 있다.
정찰(Recon) — 시간을 가장 많이 쓰는 단계
실력 좋은 헌터일수록 익스플로잇보다 정찰에 훨씬 많은 시간을 쓴다는 말이 있을 정도로 중요한 단계다.
- 서브도메인 열거:
subfinder, amass로 대상 조직의 서브도메인을 최대한 넓게 수집. 방치된 오래된 서브도메인, 개발/스테이징 서버가 취약점이 몰려있는 경우가 많다
- 살아있는 호스트 확인:
httpx로 실제 응답하는 서비스만 추려낸다
- 기술 스택 파악:
Wappalyzer, HTTP 응답 헤더로 어떤 프레임워크/CMS/서버 소프트웨어를 쓰는지 확인 — 알려진 CVE가 있는 특정 버전이면 바로 우선순위가 올라간다
- 엔드포인트/파라미터 수집:
gau, waybackurls로 과거에 인덱싱된 URL을 모으고, ffuf로 디렉터리/파라미터를 퍼징. JS 번들 파일 안에 문서화 안 된 API 엔드포인트가 그대로 노출된 경우가 흔하다
- 변경 사항 모니터링: 같은 대상을 반복적으로 스캔하면서, 새로 추가된 서브도메인이나 엔드포인트가 생기면 우선적으로 살펴본다 — 새 기능일수록 검증이 덜 된 상태일 확률이 높다
분석 — Web 카테고리 글들과 이어지는 부분
정찰로 찾은 입력 지점마다, 이 블로그의 Web 카테고리에서 다룬 취약점 클래스(SQLi, XSS, IDOR, SSRF, 파일 업로드, 인증/세션 문제 등)를 하나씩 대입해본다. 특히 초보자에게 가성비가 좋은 취약점 클래스는:
- IDOR: 코드 실력보다 "숫자/ID를 바꿔보는" 끈기가 더 중요해서 입문자가 접근하기 좋다
- 접근 제어 미비: 관리자 기능 URL을 직접 추측해서 접근되는지 확인하는 것만으로도 발견되는 경우가 많다
- 정보 노출:
.git, .env, 백업 파일, 에러 메시지의 스택 트레이스처럼 "찾기만 하면 되는" 유형
리포트 작성 — 실제로 보상을 받느냐를 가르는 단계
아무리 좋은 취약점을 찾아도 리포트가 부실하면 낮은 등급으로 처리되거나 반려된다. 좋은 리포트의 구조:
- 제목: 취약점 종류와 위치를 한 줄로 요약 (예: "IDOR in /api/orders/{id} allows viewing other users' orders")
- 재현 단계(Steps to Reproduce): 트리아저가 그대로 따라 하기만 하면 재현되도록, 계정 생성부터 최종 확인까지 번호를 매겨 구체적으로 작성. 요청/응답 원문(curl 명령어나 Burp 요청 raw)을 그대로 첨부하면 재현 속도가 훨씬 빨라진다
- 영향(Impact): "이 취약점으로 실제로 뭘 할 수 있는가"를 구체적으로 설명. "취약점이 있다"보다 "이걸로 다른 사용자의 결제 정보를 조회할 수 있다"처럼 비즈니스 임팩트로 설명해야 심각도 평가가 제대로 된다
- PoC(개념 증명): 스크린샷, 짧은 동영상, 또는 최소한의 재현 스크립트. 말로 설명하는 것보다 훨씬 신뢰도가 높다
- 수정 제안: 필수는 아니지만, 원인과 방어 방향을 한두 줄 덧붙이면 트리아저와 개발팀의 신뢰를 얻는 데 도움이 된다
흔한 초보자 실수
- 스코프 밖 테스트: 서브도메인 전체를 무차별로 스캔하다가 스코프 밖 자산까지 건드림
- 중복 신고: 이미 알려진 취약점(특히 유명 CVE 그대로)을 신고 — 신고 전에 해당 소프트웨어의 알려진 CVE 여부를 먼저 확인하는 습관이 필요
- 임팩트 증명 부족: "이 파라미터에 XSS가 될 것 같다"는 추측만 적고 실제 PoC가 없어서 반려
- DoS성 테스트로 규정 위반: 대량 요청을 보내는 자동화 스캐너를 룰 확인 없이 그대로 돌림
시작하는 순서 제안
- 이 블로그의 Web 카테고리 글들로 취약점 클래스 기초를 먼저 다진다
- PortSwigger Web Security Academy(무료)로 실습 문제를 풀며 각 취약점을 손으로 재현해본다
- 보상 압박 없이 배우기 좋은 VDP(Vulnerability Disclosure Program, 보상 없이 신고만 받는 프로그램)부터 시작해서 리포트 작성 경험을 쌓는다
- 익숙해지면 보상형 프로그램으로 넘어간다
버그바운티는 결국 "정찰 범위를 얼마나 넓고 꼼꼼하게 훑는가"와 "찾은 걸 얼마나 명확하게 전달하는가" 두 가지가 실력만큼이나 결과를 좌우한다.