rust-web-security

Rust Web Security Delivery

まず攻撃者、資産、信頼境界を確立し、その後にクレートとミドルウェアを選択します。Rust のメモリ安全性だけでは、認証、認可、プロトコルの適用、ビジネスロジックのセキュリティは自動的に確保されません。デフォルトですべて拒否し、ネガティブテストで制御が有効であることを証明してください。

セキュリティ要件の確認

変更を加える前に、以下を確認してください。

• サービスの公開面、呼び出し元、ブラウザー／API／サービス間のトラフィック、管理エンドポイントを特定します。
• TLS の終端箇所、信頼するプロキシ、クライアント IP／ホスト／スキームの取得元を確認します。
• ID プロバイダー、認証プロトコル、トークン／セッションの種類とライフサイクルを定義します。
• ロール、スコープ、オブジェクトの所有権、テナント境界、機密性の高い業務操作を明確にします。
• Cookie、パスワード、API キー、Webhook の鍵の保管と更新を管理します。
• CORS、CSRF、リダイレクト、アップロード、送信先 URL、Webhook のシナリオを設定します。
• リクエスト本文のサイズ／並列処理／タイムアウト要件と不正利用への耐性ポリシーに基づいて、レート制限の予算を定義します。
• 監査イベントの定義、プライバシー基準、コンプライアンス要件、インシデント対応手順を確立します。
• axum、tower、rustls、cookie クレートのバージョンと Rust MSRV を固定します。

セキュリティ要件が不完全な場合は、前提と未対応のリスクを明示してください。合否を得るためにテストを弱めて、検証を回避してはなりません。

ワークフロー

1. 攻撃対象領域とベースラインを確立する

rustc --version --verbose
cargo metadata --format-version 1
cargo tree -e features
cargo test --all-targets

すべてのルート、メソッド、エクストラクター、ミドルウェア、プロキシ、コールバック、管理エンドポイント、送信リクエストを列挙します。認証コンテキストの確立箇所、認可の判断箇所、セッション／トークンの保存場所、鍵の読み込み箇所、監査ログの記録箇所を特定します。既存のリポジトリのセキュリティゲートを実行します。セキュリティツールのインストールやアップグレードは、プロジェクトの制約に準拠する必要があります。

2. 脅威モデルと認可マトリックスを作成する

最低限、以下を記録します。

Asset -> Entry Point -> Trust Boundary -> Attacker Capability -> Control -> Verification Evidence

機密性の高い各操作について、主体 × アクション × リソース × テナント × コンテキストのマトリックスを作成します。認証によって証明できるのは「誰か」だけです。認可では、ユーザーがそのオブジェクトに対してこのアクションを実行できるかどうかを、すべてのリクエストで検証する必要があります。デフォルトですべて拒否し、ログイン確認やフロントエンドのボタン表示だけに依存してはなりません。

オブジェクトレベル、属性レベル、テナントベースの認可について詳しくは、脅威モデルと認可を参照してください。

3. 単一の境界でアイデンティティを確立する

• メンテナンスされているクレートを使い、成熟した IdP／プロトコルを利用します。トークン／パスワードのプロトコルを独自に作成してはなりません。
• 認証結果を最小限の Principal／クレームコンテキストに変換します。
• 認証ミドルウェアの障害時には、匿名アイデンティティへのフォールバックで気付かれないまま保護レベルが低下することなく、リクエストを終了させます。
• 認証情報がない場合または無効な場合は 401 を返し、アイデンティティが判明していても権限が拒否される場合は 403 を返します。
• 管理用、内部用、ユーザー用のアイデンティティには、それぞれ異なるオーディエンス、スコープ、または認証情報が必要です。
• 再認証、MFA、またはトランザクションの確認が必要な高リスク操作では、古いセッションに依存しないようにします。

4. トークン、セッション、パスワードを適切に検証する

JWT の検証では、署名、発行者、オーディエンス、有効期限、利用開始時刻、トークン種別／スコープの要件を検証する固定の許可アルゴリズムを適用する必要があります。トークン種別が異なる場合は、相互排他的な検証ルールと、JWKS のキャッシュ／更新処理が必要です。ヘッダー／クレームをデコードしても、有効な認証にはなりません。

Cookie セッションには、脅威モデルに適合する Secure、HttpOnly フラグと SameSite、最小限の Path を設定します。通常、広範囲に適用される Domain は省略します。ログイン後と権限昇格後にはセッション ID をローテーションし、ログアウトまたは失効時のサーバー側無効化と、絶対有効期限／アイドル有効期限を定義します。

パスワードのハッシュ化には、デプロイ環境の規模に応じて測定した Argon2id のようなパラメーターを使用する、メンテナンスされているパスワードハッシュ API を使用します。汎用の高速ハッシュは避けてください。高コストな KDF によって、非同期ランタイムのワーカーをブロックしてはなりません。API キー／トークンは一度だけ表示し、スコーププレフィックス、有効期限、更新機能を備えた検証可能な形式で保存します。OAuth/OIDC/JWT/セッション／パスワード／API キーの詳細については、認証トークンとセッションを参照してください。

5. 各リソース境界で認可する

• 認可の入力には、信頼できる主体、アクション、実際のリソース属性、テナントが含まれます。
• BOLA/IDOR 攻撃を防ぐため、まずテナントでクエリし、その後にオブジェクト／フィールドの権限を確認します。
• 管理ロールには明示的なスコープが必要です。is_admin をグローバルな制限回避手段として扱わないでください。
• バッチ操作では、オブジェクトごとに認可するか、同等のデータベースポリシーを適用します。
• 書き込み DTO では許可リストを使用し、ロール、テナント、所有者などの機密フィールドへの一括割り当てを防ぎます。
• 認可結果をキャッシュする場合は、ポリシーバージョン、サブジェクト、リソース、アクション、有効期限を含めます。

データベースの行レベルセキュリティ（RLS）は多層防御になりますが、アプリケーションレベルの戦略やテストに取って代わるものではありません。

6. ブラウザーとトランスポートの境界を強化する

• 実際の終端レイヤーで検証された HSTS、証明書、mTLS、TLS ポリシーを用いて、HTTPS を全体に適用します。
• ホスト／スキーム／IP の偽装を防ぐため、信頼できるプロキシが明示的に挿入した転送ヘッダーのみを信頼します。
• CORS はサーバー側のアクセス制御ではなく、ブラウザーからの読み取り方針を定義します。認証情報を使用する場合は、正確なオリジン許可リストを使用します。 状態を変更する Cookie ベースの認証エンドポイントでは、CSRF トークンによる防御を併用します。特定の脅威モデル内の脅威に対する保護を整合させる場合に限り、SameSite Cookie に依存します。

レスポンス本文の種類に合わせて、Content Security Policy（CSP）、フレーム、コンテンツタイプ、リファラー、キャッシュの各ヘッダーを設定します。本文サイズ、ヘッダー操作、アップロード、ページネーション、並列処理、タイムアウト、高コストな操作にレート制限を適用します。ユーザーが制御可能な URL／Webhook の制限によって SSRF を防止します。スキーム／ホスト／ポートを制限し、すべてのアドレスを解析してプライベートネットワーク／メタデータの宛先をブロックし、リダイレクト後にも再検証します。

送信レスポンスにも、サイズ／種類／時間の制約を適用します。具体的なチェックについては、ブラウザー、トランスポート、入力を参照してください。

7. シークレットを保護し、監査を確立する

• 管理された設定／シークレットマネージャーからコードにシークレットを注入し、イメージレイヤー、エラー、ログにのみ出力します。メモリ分離と同等の保護を主張することなく、Debug シリアライズによる偶発的な露出を減らすために secrecy 型を使用します。
• キー ID、所有者、用途、アルゴリズム、作成／有効期限／更新／取り消しのポリシーを明示的に定義します。
• トレースログに記録する前に、機密性の高い本文コンテンツに印を付けるか、サニタイズします。ログイン失敗、権限拒否、ポリシー／ロール／キーの変更、高リスク操作を監査します。

監査記録には、シークレットを含めずに、実行者、アクション、対象、結果、リクエスト ID、タイムスタンプを含める必要があります。攻撃者が制御可能なラベルの数を制限して、ログインジェクション攻撃を防ぎます。本番環境のキー、セッション、ユーザー、トークンをローテーションまたは失効させると、外部状態が変更されます。明示的に許可された操作のみが、これらの変更を実行できます。

8. 否定的なテストで制御を実証する

少なくとも以下を対象にします。

1. 未認証または期限切れのリクエストにおける、無効な発行者／オーディエンス／アルゴリズム／トークン種別；
2. テナントレベルの権限不足（同一テナントとテナント間）、オブジェクトの所有権、フィールドレベルの権限昇格；
3. セッション固定、ログアウト／失効のシナリオ、絶対有効期限／アイドル有効期限ポリシー；
4. 悪意のあるオリジン／Cookie 属性に対する CSRF／CORS プリフライト攻撃；
5. プライベートネットワーク、IPv6、DNS の複数アドレス解決、リダイレクト、非 HTTP スキームを介した SSRF；
6. 大きなリクエストボディ、遅いリクエスト、高い同時実行コスト、負荷の大きい認証フロー；
7. トレース ID や監査ログのシークレットを漏えいするエラーレスポンス；
8. 依存関係の脆弱性、機能／暗号バックエンドの変更。

テスト／監査／サプライチェーンのドキュメントについては、Secrets Audit and Testing を参照してください。

共通ゲート

cargo fmt --all -- --check
cargo check --all-targets
cargo test --all-targets
cargo clippy --all-targets -- -D warnings
cargo audit

cargo audit を実行するには、ツールとアドバイザリデータの両方を利用できる必要があります。どちらかが利用できない場合は、合格したと主張せず、監査を実行していないことを報告してください。リポジトリのポリシーに従い、cargo deny、DAST、プロキシ／TLS 設定テスト、認可マトリックスの検証で補完してください。

完了基準

• 脅威モデル、信頼境界、認可マトリックスが明示されている；
• すべての機密性の高いルートがデフォルトですべて拒否し、オブジェクト／テナント／アクションの所有権を検証する；
• トークン／セッション／パスワード／API キーで、完全な検証を伴う成熟したプロトコルを使用する；
• TLS／プロキシ／CORS／CSRF／ヘッダー／リソース制限が、実際のデプロイ設定に沿っている；
• シークレットがレスポンス／ログに含まれない。ローテーション／失効ポリシーが明示されている；
• 否定的なテストと依存関係の監査に合格している。未検証の IdP、プロキシ、TLS、本番環境設定には明示的に印が付けられている。

引き継ぎの境界

主な責任	担当
ルーター、エクストラクター、ハンドラー、ミドルウェア、シャットダウンロジック	rust-web
ユーザー／セッション／テナント／API キーの永続化とトランザクション	rust-database
非同期 KDF の分離、タイムアウト、キャンセル、同時実行制限	rust-concurrency
テストのレイヤリング、ファズテストのカバレッジ／パフォーマンスゲート	rust-testing
依存関係の機能、暗号バックエンド、ビルド／リリース設定	rust-cargo-build
暗号化／FFI／unsafe 実装のレビュー	rust-unsafe-ffi

オンデマンドリソース

• Threat Model and Authorization：権限、テナント境界、機密性の高いビジネスフローを設計する際に参照してください。
• Authentication Tokens and Sessions：実装中に OIDC／JWT／Cookie セッション／パスワード／API キーを扱う際に参照してください。
• Browser Transport and Input：サービスのデプロイ時に TLS／プロキシ／CORS／CSRF／ヘッダー／アップロード／SSRF チェックを設定する際に参照してください。
• Secrets Audit and Testing：実装中にシークレット、ログ、否定的なテスト、依存関係の監査を扱う際に参照してください。
• Crypto Dependency Boundaries：AEAD／KDF／定時間処理／消去用のクレートを選定する際や、暗号機能の実装時に nonce／トランスクリプト／WASM またはプロトコルのバージョンをレビューする際に参照してください。
• Example Scenarios：本番環境に対応した例を必要とするエンドツーエンドのタスク分解テンプレートについて参照してください。

examples/golden-authorization/：デフォルト拒否／オブジェクト／テナント認可のゴールデンテストを、オフラインでコンパイルおよび検証できます。