rust-service-security

Rust サービスのセキュリティ

Rust サービスが、ID、認証情報、セッション、Cookie、特権ルート、または機密性の高いユーザーデータを扱う場合は、このスキルを使用してください。楽観的なハンドラーコードよりも、明示的な脅威チェックとテストを優先してください。

基本的なワークフロー

1. 保護対象の資産を特定します。アカウントアクセス、管理領域、セッション状態、パスワード変更、リセットトークン、プライベートデータ、または特権操作などです。
2. リクエストの解析、認証情報の検索、検証、セッションの変更、リダイレクトやレスポンス、ログ、テストまで、フロー全体を追跡します。
3. シークレットをログやデバッグ出力に含めないでください。パスワード、トークン、署名キー、セッションシークレットにはシークレット用ラッパーを使用します。
4. メモリハードなアルゴリズムでパスワードのハッシュ化と検証を行い、CPU 負荷の高い処理を非同期リアクタースレッドから移します。
5. ユーザーの列挙を防ぎます。ログイン失敗時やパスワードリセットのフローでは、アカウントの有無が分からないようにしてください。
6. Cookie とセッションの属性を意図的に設定します。HttpOnly、Secure、SameSite、パス、ライフタイム、署名／暗号化、ストアのバックエンドなどです。
7. その場しのぎのチェックを各ハンドラーで繰り返すのではなく、ミドルウェアまたはエクストラクターの境界でルートを保護します。
8. 正常系、認証失敗、セッション欠落、偽造された Cookie やトークン、ログアウト／セッションローテーションの動作をテストします。

パスワードのルール

パスワードの保存または検証を実装・変更する前に、references/password-auth.md を読んでください。

• Argon2id、またはプロジェクトで選択したパスワードハッシュ関数が生成する PHC 文字列を保存します。平文のパスワードや、復号可能な暗号化パスワードは決して保存しないでください。
• 安全な RNG でソルトを生成します。
• 認証情報が無効な場合は、一定の汎用的なレスポンスを使用します。
• 負荷の高いパスワード処理には、tokio::task::spawn_blocking または専用のブロッキング抽象化を使用します。
• パスワードハッシュのパラメーターは、将来的にアップグレードできる程度に設定可能にしておきます。

Cookie とセッションのルール

Cookie とセッションの設定、読み取り、削除、署名、または永続化を行う場合は、references/cookies-sessions.md を読んでください。

• 生の認証情報を Cookie に保存しないでください。
• 特権アプリでは、サーバー側ストアで管理する不透明なセッション ID を優先します。
• ログイン後や権限変更後に、セッション状態をローテーションまたは更新します。
• サーバー側ストアを使用している場合は、ログアウト時にサーバー側でセッションを削除します。
• Set-Cookie ヘッダーのセキュリティ属性をテストします。

ルートの保護

管理ルート、エクストラクター、ガード、またはフレームワークのミドルウェアを追加する場合は、references/auth-middleware.md を読んでください。

ハンドラーには型を付けます。

pub async fn admin_dashboard(user: AuthenticatedUser) -> Result<HttpResponse, AppError> {
    // Handler can assume authentication succeeded.
    Ok(HttpResponse::Ok().finish())
}

認証が必要なハンドラーで、ユーザーをオプショナルに検索することは避けてください。フレームワークで可能な場合は、ハンドラーのシグネチャでユーザー不在のケースが起こり得ないようにします。

リファレンスファイル

• references/password-auth.md：Argon2、PHC 文字列、ユーザー列挙、ブロッキング方式でのパスワード処理。
• references/cookies-sessions.md：Cookie のフラグ、署名付きメッセージ、サーバー側セッション、ログアウト。
• references/auth-middleware.md：ルートガード、エクストラクター、型付きのセッションアクセス。