セキュリティバウンティハンター は何をしますか？
これは、広範なベストプラクティスレビューではなく、責任ある開示やバウンティ提出のための実用的な脆弱性発見を目的とする場合に使用します。
使用するタイミング
- 悪用可能な脆弱性をリポジトリでスキャンする場合
- 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 - セキュリティヘッダーの欠如だけ
- 悪用影響がない一般的なレート制限の苦情
- 被害者が手動でコードを貼り付ける必要がある自己XSS
- ターゲットプログラムの範囲外のCI/CDインジェクション
- デモ、サンプル、またはテスト専用コード
ワークフロー
- 最初にスコープを確認：プログラムルール、SECURITY.md、開示チャネル、除外事項。
- 実際のエントリポイントを見つける：HTTPハンドラ、アップロード、バックグラウンドジョブ、ウェブフック、パーサー、統合エンドポイント。
- 静的ツールが役立つ場合は実行するが、トリアージの入力としてのみ扱う。
- 実際のコードパスを最初から最後まで読む。
- ユーザー制御が意味のあるシンクに到達することを証明する。
- 最小限の安全なPoCで悪用可能性と影響を確認する。
- 報告書を作成する前に、重複を確認する。
トリアージループの例
semgrep --config=auto --severity=ERROR --severity=WARNING --json
その後、手動でフィルタリング：
- テスト、デモ、フィクスチャ、ベンダーコードを削除
- ローカルのみまたは到達不能なパスを削除
- 明確なネットワークまたはユーザー制御経路がある発見のみを保持
報告書の構造
## 説明
[脆弱性の内容とその重要性]
## 脆弱なコード
[ファイルパス、行範囲、および小さいスニペット]
## 概念実証
[最小限の動作するリクエストまたはスクリプト]
## 影響
[攻撃者が達成できること]
## 影響を受けるバージョン
[テストしたバージョン、コミット、またはデプロイ先]
品質ゲート
提出前の確認事項：
- コードパスが実際のユーザーまたはネットワーク境界から到達可能であること
- 入力が実際にユーザー制御下にあること
- シンクが意味を持ち、悪用可能であること
- PoCが動作すること
- 問題がすでに勧告、CVE、またはオープンチケットでカバーされていないこと
- ターゲットが実際にバウンティプログラムの対象範囲内であること