hakluke/bug-bounty-standardsバグ報奨金プログラムで発生するエッジケースの一覧と、それらの対処方法に関する議論。目標は、バグ報奨金において特定の状況が処理される方法を標準化することです。
このリポジトリは、バグ報奨金プログラムで発生する状況と、それらをどのように処理すべきかをまとめたリストです。これらの多くは現在、ケースバイケースで処理されており、ハッカー、プログラムオーナー、プラットフォームに多くの不確実性と不満をもたらしています。このリポジトリの目標は、これらのエッジケースがすべての報奨金プラットフォームおよびプログラムで処理される方法を標準化することです。標準化により、すべての関係者からの期待がより頻繁に満たされることを願っています。
この文書はドラフトであり、まだいかなるバグ報奨金プラットフォームにも実装されていません。現段階では、すべての利害関係者からのコメントを求めています。
GitHub issue を開いて貢献してください。提出された合理的な issue はすべて、コメント受付のため最低30日間オープンのままとなります。
issue には意見を記載してください。例：
issue へのコメントは誰でも歓迎されますが、建設的かつ感情を排したものでなければなりません。虐待的な行為は許容されません。
| ID | 状況 | 解決策 |
|---|
| 1 | ハッカーが悪用の証明とともに脆弱性を提出する。提出物がトリアージされる前に脆弱性が修正される。 | プラットフォームは、修正前に提出物がプログラムによってアクセスされていなかったことを証明しなければならない。提出物がプログラムによってアクセスされていた場合、プログラムは該当する報奨金を支払うべきであり、そうでない場合は提出物は重複としてマークされる。 |
| 2 | ハッカーが脆弱性を提出し、プログラムが内部ですでに把握していたと回答する。 | プログラムは、これが以前から既知の問題であったことを証明しなければならない。例えば、作成日を含む Jira チケットのスクリーンショットなど。プログラムが証明を提供できない場合、報奨金を支払うべきであり、そうでない場合は提出物は重複としてマークされるべきである。 |
| 3 | ハッカーが脆弱性を提出し、そのバグの影響を完全には調査していなかった別の提出物の重複としてマークされる。例えば、ハッカーがアカウント乗っ取りを可能にする完全な XSS を提出し、HTML インジェクションのみを報告した別の提出物に対して重複とされる。 | 最初の報告者は自分の提出物の影響に基づいて報奨金を受け取り、2番目の報告者は自分の提出物の影響から最初の報告者が受け取った報奨金を差し引いた額を受け取る。 |
| 4 | ハッカーが脆弱性を提出するが、プログラムが一切応答しない。 | プラットフォームが報奨金を支払う。 |
| 5 | ハッカーが脆弱性を提出し、より新しいレポートに対して誤って重複とされる。 | プラットフォームは両方のレポートのステータスを正確なものに変更する。誤った支払いがすでに行われている場合、誤ってトリアージした組織が報奨金を支払う。マネージド報奨金プログラムの場合、これは通常プラットフォームとなるが、アンマネージドプログラムの場合はプログラムとなる。 |
| 6 | ハッカーが割り当てられた深刻度評価に同意しない。 | ハッカーは根拠をチケットに提出する。14日間応答がない場合、ハッカーは根拠をプラットフォームのサポートチャネルに提出する。深刻度の引き上げは提出物ごとに決定される。 |
| 7 | ハッカーが、プログラムオーナーから明示的な許可を得ずに、以前プラットフォームに提出されたバグを公開開示する。 | 研究者は以下の状況下で脆弱性を公開開示できるべきである：a) バグが有効として承認されていない、すなわち N/A または Informative とマークされている。b) バグが解決済み状態に30日以上ある。c) 研究者がプログラムから公開開示の明示的な許可を得ている。その他の場合、ハッカーはプラットフォームから30日間の禁止を受け、禁止の理由の詳細がハッカーにメールで送信される。繰り返しの違反は永久追放となる。 |
| 8 | ハッカーがプログラムのスコープ内にあるバグを提出するが、実際にはサードパーティサービスのバグである。 | すべてのプログラムは、そのブリーフ内でサードパーティシステムのバグを受け入れるかどうかを指定すべきである。指定がない場合、サードパーティシステムを含むスコープに記載されたすべてのシステムが支払いの対象として有効であると見なされる。 |
| 9 | ハッカーが、公開されたエクスプロイトや開示が存在しない、スコープ内のシステムに影響を与えるゼロデイ脆弱性を提出する。 | レポートの結果として何らかの変更が行われた場合、すなわち設定変更、システムのオフライン化、WAF ルールの適用などがあれば、レポートは受理され報奨金が支払われるべきである。公開されているゼロデイエクスプロイトと、バグ報奨金レポートがなければチームが知り得なかったであろうゼロデイエクスプロイトとを区別しなければならない。 |
| 10 | ハッカーが、オープンスコープのブリーフを持つプログラムにバグを提出する。バグは買収した企業に関するものである。プログラムオーナーは買収した企業の IT インフラストラクチャやスタッフを管理していない。 | プログラムオーナーは、プラットフォームによって検証された誠実な努力をもって、買収した企業に通知すべきである。買収した企業が提出物から利益を得る場合、プログラムオーナーは報奨金を支払うべきである。買収した企業がスコープ内かどうかを反映するためにブリーフを更新すべきである。 |
