Fix for IDOR in tRPC routes via verifyProjectAccess

脆弱性の概要 この脆弱性は、tRPC ルートにおけるプロジェクトメンバーシップ認可（IDOR、不正なオブジェクト参照）の強制に関するものです。Drizzle クライアントが RLS（Row Level Security）をバイパスする Postgres スーパーユーザーとして接続するため、認可は tRPC プロシージャのコード内で強制する必要があります。 関数は存在しますが、一部のプロシージャにのみ適用されており、その他のすべてのプロジェクトスコープのプロシージャはクライアントから提供された を使用しているため、認証済みユーザーが他のユーザーのリソースにアクセスできる状態が生まれていました。 影響範囲 影響を受けるtRPCルート： 、 （会話/メッセージ/提案）、 、 、 、 、 、 （デプロイ/公開解除）、 （プレビュー/カスタム/検証）、 （getByIdは自分自身のみ、upsert はセッションユーザーに固定）、 、 、 、 。 具体的な影響：認可されていないアクセスにより、データ漏洩やリソースの濫用などのセキュリティ上の問題が発生する可能性があります。 修正方針 1. パターンを適用する：各プロジェクトスコープのプロシージャにこのパターンを適用し、「未許可または見つかりません」という統合されたエラーを共有することで、リソースの存在性を列挙できないようにします。 2. 新しいヘルパー関数の追加： - ：プロジェクトへのアクセス権限を検証します。 - ：会話へのアクセス権限を検証します。 - ：メッセージへのアクセス権限を検証します。 - ：ブランチへのアクセス権限を検証します。 - ：キャンバスへのアクセス権限を検証します。 - ：フレームへのアクセス権限を検証します。 - ：招待へのアクセス権限を検証します。 - ：サンドボックスへのアクセス権限を検証します。 - ：デプロイへのアクセス権限を検証します。 - ：ドメイン検証へのアクセス権限を検証します。 - ：アクセス可能なサンドボックスIDを列挙します。 3. ルートの強化： 、 、 、 、 、 、 、 、 、 、 、 、 、 などのルートに対する強化処理を行います。 4. その他の改善： - を ブロックから外し、拒否が飲み込まれるのを防ぐため を返すブロックを使用します。 - 誤った拒否を防止するために、繰り返しIDの代わりに を使用します。 - のスコープを呼び出し元のカaller の に限定します。 - の処理において をスローします。 テスト/チェック 認可ヘルパーのユニットテストのカバレッジ： （メンバーの通過、非メンバー/欠如したロールの拒否、未命名時のサンドボックスの許可、リストのスコープを含む19ケース）。 Webクライアント上で と を実行します。 メンテナには、完全な テストスイートを実行し、ローカルのPostgres上で元々の「複数のtRPCプロシージャ間をまたぐクロスユーザーIDOR」の問題をテストすることをお勧めします。 スコープ外/後続作業 は （認証なし）を使用していますが、 にマウントされていません（デッドコードであり）、以前にゲーティングを行う必要があります。 （ 、 、任意URLのスクレイピング）は別カテゴリの問題であり、この差分には含まれません。 コード例 以上が、この脆弱性に関する簡潔な日本語要約です。

目標達成すべての支援者に感謝 — 100%達成しました！

Fix for IDOR in tRPC routes via verifyProjectAccess

このソースからの他の記事

目標達成 すべての支援者に感謝 — 100%達成しました！

Fix for IDOR in tRPC routes via verifyProjectAccess

このソースからの他の記事

目標達成すべての支援者に感謝 — 100%達成しました！