hakluke/bug-bounty-standards버그 바운티 프로그램에서 발생하는 엣지 케이스 목록과 그 처리 방법에 대한 논의입니다. 목표는 버그 바운티에서 특정 상황이 처리되는 방식을 표준화하는 것입니다.
이 저장소는 버그 바운티 프로그램에서 발생하는 상황들과 그 처리 방법에 대한 목록입니다. 현재 이 중 많은 부분이 사례별로 처리되고 있어 해커, 프로그램 소유자, 플랫폼 모두에게 많은 불확실성과 불만을 야기합니다. 이 저장소의 목표는 모든 바운티 플랫폼과 프로그램에서 이러한 예외 사례들을 처리하는 방식을 표준화하는 것입니다. 표준화를 통해 모든 당사자의 기대가 더 자주 충족되기를 바랍니다.
이 문서는 초안이며 아직 어떤 버그 바운티 플랫폼에서도 구현되지 않았습니다. 현재 단계에서는 모든 이해 관계자들의 의견을 요청하고 있습니다.
GitHub 이슈를 열어 기여해 주세요. 제출된 모든 합리적인 이슈는 의견 수렴을 위해 최소 30일 동안 열려 있습니다.
이슈에는 의견이 명시되어야 합니다. 예:
이슈에 대한 의견은 누구나 환영하지만 건설적이고 감정적이지 않아야 합니다. 학대적인 행동은 용납되지 않습니다.
| ID | 상황 | 해결 방안 |
|---|
| 1 | 해커가 악용 증거와 함께 취약점을 제출한다. 제출물이 분류되기 전에 취약점이 수정된다. | 플랫폼은 제출물이 해결 전에 프로그램에 의해 접근되지 않았다는 증거를 제공해야 한다. 제출물이 프로그램에 의해 접근된 경우 프로그램은 해당 포상금을 지불해야 하며, 그렇지 않으면 제출물은 중복으로 표시된다. |
| 2 | 해커가 취약점을 제출하면 프로그램이 내부적으로 이미 알고 있었다고 응답한다. | 프로그램은 이전에 알려진 문제였음을 증명해야 한다. 예를 들어 생성 날짜가 포함된 Jira 티켓의 스크린샷이 그 증거가 될 수 있다. 프로그램이 증거를 제시할 수 없으면 포상금을 지불해야 하며, 그렇지 않으면 제출물은 중복으로 표시되어야 한다. |
| 3 | 해커가 취약점을 제출하고, 버그의 영향을 완전히 탐구하지 않은 다른 제출물의 중복으로 표시된다. 예를 들어, 해커가 계정 탈취를 가능하게 하는 전체 XSS를 제출했는데, HTML 삽입만 보고한 다른 제출물에 대해 중복 처리되는 경우다. | 첫 번째 신고자는 자신의 제출물의 영향에 따라 포상금을 받고, 두 번째 신고자는 자신의 제출물의 영향에서 첫 번째 신고자가 받은 포상금을 뺀 금액을 받는다. |
| 4 | 해커가 취약점을 제출했지만 프로그램이 전혀 응답하지 않는다. | 플랫폼이 포상금을 지불한다. |
| 5 | 해커가 취약점을 제출했는데, 해커가 더 새로운 보고서에 대해 잘못 중복 처리된다. | 플랫폼은 두 보고서의 상태를 정확하게 변경한다. 이미 잘못 지불이 이루어진 경우, 잘못 분류한 조직이 포상금을 지불한다. 관리형 바운티 프로그램의 경우 이는 일반적으로 플랫폼이지만, 비관리형 프로그램의 경우 프로그램이다. |
| 6 | 해커가 부여된 심각도 등급에 동의하지 않는다. | 해커는 티켓에 근거를 제출한다. 14일 동안 응답이 없으면 해커는 플랫폼의 지원 채널에 근거를 제출한다. 심각도 상향은 제출물별로 결정된다. |
| 7 | 해커가 프로그램 소유자의 명시적 허가 없이 이전에 플랫폼에 제출된 버그를 공개적으로 공개한다. | 연구자는 다음 상황에서 취약점을 공개적으로 공개할 수 있어야 한다: a) 버그가 유효한 것으로 승인되지 않은 경우, 즉 N/A 또는 정보성(Informative)으로 표시된 경우. b) 버그가 해결 상태로 30일 이상 지속된 경우. c) 연구자가 프로그램으로부터 공개적 공개에 대한 명시적 허가를 받은 경우. 그 외의 경우, 해커는 플랫폼에서 30일 금지 조치를 받으며, 금지 조치에 대한 전체 사유를 이메일로 받는다. 재범 시 영구 금지 조치를 받는다. |
| 8 | 해커가 프로그램의 범위 내에 있는 버그를 제출하지만, 실제로는 제3자 서비스의 버그다. | 모든 프로그램은 프로그램 브리프 내에서 제3자 시스템의 버그를 수용하는지 여부를 명시해야 한다. 명시가 없는 경우, 범위에 나열된 모든 시스템이 제3자 시스템을 포함하여 지불 대상으로 간주된다. |
| 9 | 해커가 공개된 악용 코드나 공개 정보가 없는 제로데이 취약점을 범위 내 시스템에 영향을 미치는 상태로 제출한다. | 보고서의 결과로 어떤 변경이라도 이루어진 경우, 즉 구성 변경, 시스템 오프라인 전환, WAF 규칙 적용 등이 있다면 보고서는 수락되고 보상되어야 한다. 공개된 제로데이 악용과 버그 바운티 보고서가 없었더라면 팀이 알지 못했을 제로데이 악용을 구분해야 한다. |
| 10 | 해커가 개방형 범위 브리프를 가진 프로그램에 버그를 제출한다. 버그는 피인수 기업에 있다. 프로그램 소유자는 피인수 기업의 IT 인프라나 직원을 통제하지 않는다. | 프로그램 소유자는 플랫폼이 검증하는 선의의 노력으로 피인수 기업에 알려야 한다. 피인수 기업이 제출물로부터 이익을 얻는다면, 프로그램 소유자는 포상금을 지불해야 한다. 피인수 기업(들)이 범위에 포함되는지 여부를 반영하도록 브리프가 업데이트되어야 한다. |
