find-bugs

バグの検出

このブランチの変更を確認し、バグ、セキュリティ上の脆弱性、コード品質の問題を見つけてください。

フェーズ 1：入力情報の完全な収集

1. 差分全体を取得します：git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD
2. 出力が途中で切れている場合は、変更された各ファイルを個別に読み、変更行をすべて確認します
3. 次に進む前に、このブランチで変更されたファイルをすべて列挙します

フェーズ 2：攻撃対象領域の把握

変更された各ファイルについて、以下を特定して列挙します。

• すべてのユーザー入力（リクエストパラメーター、ヘッダー、本文、URL の構成要素）
• すべてのデータベースクエリ
• すべての認証／認可チェック
• すべてのセッション／状態操作
• すべての外部呼び出し
• すべての暗号処理

フェーズ 3：セキュリティチェックリスト（各ファイルについて、すべての項目を確認）

• インジェクション：SQL、コマンド、テンプレート、ヘッダーのインジェクション
• XSS：テンプレート内のすべての出力が適切にエスケープされていますか？
• 認証：保護対象のすべての操作で認証チェックが行われていますか？
• 認可／IDOR：認証だけでなく、アクセス制御も確認されていますか？
• CSRF：状態を変更する操作が保護されていますか？
• 競合状態：読み取り後に書き込む処理に TOCTOU はありませんか？
• セッション：固定化、有効期限、セキュアフラグに問題はありませんか？
• 暗号処理：安全な乱数と適切なアルゴリズムを使用し、ログに秘密情報を出力していませんか？
• 情報漏えい：エラーメッセージ、ログ、タイミング攻撃に問題はありませんか？
• DoS：上限のない処理、レート制限の欠如、リソース枯渇の可能性はありませんか？
• ビジネスロジック：エッジケース、状態遷移違反、数値オーバーフローに問題はありませんか？

フェーズ 4：検証

潜在的な問題ごとに、以下を行います。

• 変更されたコード内の別の箇所ですでに対処されていないか確認します
• 該当するシナリオをカバーする既存のテストを検索します
• 周辺のコンテキストを読み、問題が実際に存在することを確認します

フェーズ 5：結論前の監査

最終化する前に、必ず以下を行ってください。

1. レビューしたすべてのファイルを列挙し、完全に読んだことを確認します
2. チェックリストの全項目を列挙し、問題が見つかったか、問題がないことを確認したかを記載します
3. 十分に検証できなかった箇所とその理由を列挙します
4. その後でのみ、最終的な検出結果を提示します

出力形式

優先順位：セキュリティ上の脆弱性 ＞ バグ ＞ コード品質

対象外：スタイルや書式の問題

問題ごとに、以下を記載します。

• ファイル:行番号 - 簡潔な説明
• 重大度：Critical／High／Medium／Low
• 問題：何が問題なのか
• 根拠：これが実際の問題である理由（すでに修正されていないこと、既存のテストがないことなど）
• 修正方法：具体的な提案
• 参考資料：該当する場合は OWASP、RFC、その他の標準

重大な問題が見つからなかった場合は、そのように伝えてください。問題を作り上げないでください。

変更は加えず、検出結果のみを報告してください。対応するかどうかは私が判断します。