チャレンジ別パターン: 認証・セッション系 (IDOR / CSRF / Mass Assignment / Timing Attack)

[mincemaker]

背景

認証・セッション・アクセス制御系チャレンジの 同じ脆弱性・別シナリオ パターンまとめ。
slot 競合機構でランダム選択される設計を想定。

IDOR (CWE-284)

既存 slot への別パターン (idor と競合)

• 添付ファイルの IDOR: Attachment.find(params[:id]).file (所有者確認なし) → 他ユーザーの添付ファイルをダウンロードできる

新 slot: ProfilesController#show

• User.find(params[:id]).profile でアクセス制御なし → 他ユーザーのプロフィール閲覧

CSRF (CWE-352)

既存 slot への別パターン (csrf_disable と競合)

• 特定アクションだけ skip: skip_before_action :verify_authenticity_token, only: [:update] — グローバルではなく部分的に無効化するパターン
• protect_from_forgery with: :null_session — 例外を上げず無効セッションで処理を続行する「緩い」無効化

Mass Assignment (CWE-915)

既存 slot への別パターン (mass_assignment と競合)

• params.require(:task).permit(:title, :description, :admin) で管理者フラグを誤って permit するパターン
• assign_attributes(params[:task].to_unsafe_h) で全属性を一括更新

Timing Attack (CWE-208)

既存 slot への別パターン (timing_attack と競合)

• API トークン検証に ==: ApiKey.find_by(token: params[:token]) — DB ルックアップの有無で差が出るパターン
• TOTP コード検証に ==: expected_code == params[:code] — 6 桁数値の文字列比較で差が出るパターン

実装上の注意

• TOTP パターンは API または二要素認証のフローが必要なため、既存アーキテクチャへの追加コストが高い
• 添付ファイル IDOR は既存の ActiveStorage 設定があれば実装しやすい