Security Bounty Hunter
목표가 광범위한 모범 사례 검토가 아닌, 책임 있는 공개 또는 바운티 제출을 위한 실질적인 취약점 발견일 때 사용하세요.
사용 시기
- 리포지토리에서 익스플로잇 가능한 취약점 스캔
- Huntr, HackerOne 또는 유사한 바운티 제출 준비
- "이론적으로 안전하지 않은가?" 보다는 "이게 실제로 돈이 되는가?"라는 질문에 대한 트라이지
작동 방식
원격에서 접근 가능하고 사용자가 제어하는 공격 경로에 편향되며, 플랫폼에서 일반적으로 정보 제공용 또는 범위 외로 거부하는 패턴은 버립니다.
범위 내 패턴
다음은 일관되게 중요하게 다뤄지는 문제 유형입니다:
| 패턴 | CWE | 일반적인 영향 |
|---|---|---|
| 사용자 제어 URL을 통한 SSRF | CWE-918 | 내부 네트워크 접근, 클라우드 메타데이터 도용 |
| 미들웨어 또는 API 가드의 인증 우회 | CWE-287 | 무단 계정 또는 데이터 접근 |
| 원격 역직렬화 또는 업로드-투-RCE 경로 | CWE-502 | 코드 실행 |
| 접근 가능한 엔드포인트의 SQL 인젝션 | CWE-89 | 데이터 유출, 인증 우회, 데이터 파괴 |
| 요청 핸들러의 명령어 인젝션 | CWE-78 | 코드 실행 |
| 파일 서빙 경로의 경로 탐색 | CWE-22 | 임의 파일 읽기 또는 쓰기 |
| 자동 트리거 XSS | CWE-79 | 세션 도용, 관리자 권한 탈취 |
건너뛰기
다음은 일반적으로 신호가 약하거나 프로그램에서 달리 명시하지 않는 한 바운티 범위를 벗어납니다:
- 원격 경로가 없는 로컬 전용
pickle.loads,torch.load또는 이와 동등한 것 - CLI 전용 도구의
eval()또는exec() - 완전히 하드코딩된 명령어에 대한
shell=True - 그 자체로 누락된 보안 헤더
- 익스플로잇 영향이 없는 일반적인 속도 제한 불만
- 피해자가 코드를 수동으로 붙여넣어야 하는 Self-XSS
- 대상 프로그램 범위에 속하지 않는 CI/CD 인젝션
- 데모, 예제 또는 테스트 전용 코드
워크플로우
- 먼저 범위를 확인하세요: 프로그램 규칙, SECURITY.md, 공개 채널 및 제외 사항.
- 실제 진입점을 찾으세요: HTTP 핸들러, 업로드, 백그라운드 작업, 웹훅, 파서 및 통합 엔드포인트.
- 도움이 되는 곳에 정적 도구를 사용하되, 트라이지 입력으로만 취급하세요.
- 실제 코드 경로를 처음부터 끝까지 읽으세요.
- 사용자 제어가 의미 있는 싱크에 도달하는지 증명하세요.
- 가장 작은 안전한 PoC로 익스플로잇 가능성과 영향을 확인하세요.
- 보고서 초안을 작성하기 전에 중복 여부를 확인하세요.
예제 트라이지 루프
semgrep --config=auto --severity=ERROR --severity=WARNING --json
그런 다음 수동으로 필터링:
- 테스트, 데모, 픽스처, 벤더 코드는 제외
- 로컬 전용 또는 접근 불가능한 경로는 제외
- 명확한 네트워크 또는 사용자 제어 경로가 있는 발견만 유지
보고서 구조
## 설명
[취약점이 무엇이며 왜 중요한지]
## 취약 코드
[파일 경로, 줄 범위 및 작은 코드 조각]
## 개념 증명
[최소한의 작동 요청 또는 스크립트]
## 영향
[공격자가 달성할 수 있는 것]
## 영향 받는 버전
[테스트된 버전, 커밋 또는 배포 대상]
품질 관문
제출하기 전에:
- 코드 경로가 실제 사용자 또는 네트워크 경계에서 도달 가능한가
- 입력이 진정으로 사용자 제어인가
- 싱크가 의미 있고 익스플로잇 가능한가
- PoC가 작동하는가
- 문제가 이미 권고, CVE 또는 열린 티켓으로 다뤄지지 않았는가
- 대상이 실제로 바운티 프로그램 범위 내에 있는가