security-check

セキュリティチェック

ハードゲート: 認証情報の取り扱い

CREDENTIAL HANDLING (W007 — Insecure Credential Exposure Defense):
- NEVER reproduce credentials, tokens, API keys, passwords, or secrets verbatim
  in output — flag by file path and line number only.
- When a finding involves secrets in code or logs, report:
    Affected file: app/config/initializers/foo.rb:12
    Finding: API key present in plain text — move to Rails credentials or ENV
  Do NOT quote the secret value itself.
- Exploitability Verification sub-sections MUST use generic placeholder values
  (e.g. "<REDACTED>", "<TOKEN>") — never the actual credential.
- If a file scan returns a secret value, stop — report its location, not its content.

クイックリファレンス

領域	主なチェック項目
認証	すべての機密操作に対する権限
パラメータ	permit! を使わない、安全な属性のみを許可リストに
クエリ	パラメータ化 — SQL に文字列補間をしない
リダイレクト	相対パスまたは許可リストに制限
出力	ユーザーコンテンツに html_safe/raw を使わない
シークレット	認証情報は暗号化し、コードやログには絶対に含めない
ファイル	ファイル名、コンテンツタイプ、保存先を検証

コアプロセス

核心原則: スタイルよりも悪用可能な問題を優先してください。すべての信頼できない入力を悪用される可能性があるものとして扱ってください。

0. ワークスペースを調査する

検出事項や分析を書く前に、必ず検索ツールとディレクトリ一覧表示ツールを実行して、ワークスペース内のソースファイル（例: コントローラー、モデル、設定ファイル）を見つけてください。見つかった実際のファイルに対してコードレベルのセキュリティレビューを実施してください。ワークスペースが完全に空である場合にのみ、チェックリストを返し、ソースファイルが提供されなかったことを述べてよいものとします。

レビュー順序

この順序でレビューし、同じ順序で出力セクションを作成してください:

1. 認証と認可の境界。
2. パラメータの処理と機密属性の代入。
3. リダイレクト、レンダリング、出力エンコーディング。
4. ファイル処理、ネットワーク呼び出し、バックグラウンドジョブの入力。
5. シークレット、ロギング、運用上の露出。
6. 各検出事項を検証する: 報告する前に、具体的な攻撃シナリオで悪用可能であることを確認してください。誤検知（例: 開発者が定義した定数に対する html_safe であり、ユーザー入力ではないもの）は除外してください。

検証ゲート: 最初の出力セクションは常に「認証と認可」でなければなりません。認証/認可の問題が存在しない場合は、他のカテゴリより前に「認証と認可: 問題なし」で始めてください。

重大度レベル

高

• 認可の欠落/バイパス可能 — 保護されていない機密操作
• インジェクション — ユーザー入力による SQL、シェル、YAML、または定数化
• 安全でないリダイレクト / SSRF — ユーザーが制御する値によって駆動される外部リクエストまたはリダイレクト
• ファイルアップロードの無条件信頼 — ファイル名、コンテンツタイプ、保存先が未検証
• コード/ログ内のシークレット — トークンや認証情報がコミットまたは出力されている

中

• 脆弱なパラメータフィルタリング — permit! またはスコープなしのマスアサインメント
• サニタイズされていない HTML 出力 — ユーザーが制御するコンテンツがサニタイズなしでレンダリングされている
• 平文の機密ロギング — ログステートメント内の PII または認証情報
• 隠れたセキュリティ挙動 — ガードレールなしでコールバックやジョブに埋め込まれた認証ロジック
• 脆いカスタム認証 — フレームワークのプリミティブが安全に提供するものを再実装している

例

高重大度（スコープなしリダイレクト）:

# Bad: user-controlled redirect — open redirect / phishing risk
redirect_to params[:return_to]

# Good: relative path only
redirect_to root_path
# Good: allowlist
SAFE_PATHS = %w[/dashboard /settings].freeze
redirect_to(SAFE_PATHS.include?(params[:return_to]) ? params[:return_to] : root_path)

中重大度（マスアサインメント）:

# Bad: privilege escalation risk
params.require(:user).permit!

# Good: explicit allowlist — never include role, admin, or privilege fields
params.require(:user).permit(:name, :email)

出力スタイル

セキュリティ監査の実施を求められた場合、出力には必ず以下を含めてください:

1. セクション順序 — 指定された正確な順序でレビュー領域ごとに1つのセクション。空のセクションには「問題なし」と書き、そのカテゴリを検証するためにどのような証拠が必要かを記述してください
2. 検出事項の詳細 — 各検出事項には以下を含めます:
   • 重大度: 高 または 中（「クリティカル」ではない）
   • 攻撃パス: 入力 → 到達 → 影響
   • 影響を受けるファイル: パス + 行、例: app/controllers/documents_controller.rb:42
   • 緩和策: 最小限の実現可能な修正
   • 仮説上の悪用可能性検証 サブセクション: 悪用可能性を証明する具体的な脆弱性の例とエクスプロイトリクエスト/ペイロード。このサブセクションは検証ステップと品質ゲートの内部に属し、トップレベルのセクションにしてはなりません。
3. 推測パスの禁止 — ソースコードが分析されない場合、SRC_DIR/ や HYPOTHETICAL_DIR/hypothetical_controller.rb のような汎用プレースホルダーを使用してください
4. 言語 — 明示的に別途要求されない限り、英語でなければなりません

拡張リソース（段階的開示）

これらのファイルは、その具体的な内容が必要な場合にのみ読み込んでください：

• PITFALLS.md — よくあるセキュリティの落とし穴や避けるべき誤検知の詳細な例が必要な場合に使用します

統合

スキル	組み合わせるタイミング
code-review	セキュリティ以外の懸念も含めた完全なコードレビューを行う場合
review-architecture	セキュリティ問題がアーキテクチャ上の問題に起因する場合
review-migration	マイグレーションのセキュリティ（データ露出、制約）をレビューする場合
security-review-process （ruby-core-skills から）	プロセスの規律：OWASP チェックリスト、Ruby レベルのセキュリティ懸念