アクセス制御層の前に検証層を持つことは問題ありませんか

私はAPI構造のWebアプリケーションを作成していますが、このアプリケーションには独自の仕事をしているさまざまなレイヤーがあります。

最初のレイヤーはユーザー入力を検証する検証レイヤーであり、検証に合格した場合は2番目のレイヤー（アクセス制御レイヤー）に移動します。そうでない場合はエラーメッセージを返します

2番目の層は、ユーザーが実行したいタスクを実行する許可を持っているかどうかを確認するアクセス制御です。ユーザーが許可を持っている場合、要求を次の層に移動します。

3番目のレイヤーは、アプリケーションのロジックがあるコントローラーレイヤーです。

私の質問は、アクセス制御の前に検証レイヤーを持つことはOKですか？ユーザーが許可されていないタスクを実行しようとしており、検証エラーメッセージを送信している場合はどうなりますか？ユーザーはリクエストをエンドポイントに送信し、検証レイヤーと話します。検証に合格すると、メッセージが表示されます。You can't access this!

私には奇妙に感じますが、このようにうまくいくのでしょうか、それともインフラストラクチャの他の選択肢は何でしょうか？

許可されていないタスクの入力の有効性を知ることがセキュリティリークであるかどうかによって異なります。もしそうなら、あなたは本当に逆にそれをするべきです。

許可されていないユーザーに対する唯一の安全な応答は「アクセス拒否」です。応答が「不正な要求」である場合と「アクセス拒否」である場合、権限のないユーザーに情報を送信しています。

例として、名前付きドキュメントが存在することを「ドキュメントの削除」タスクの検証でチェックすることができます。権限のない人は、削除しようとするものと、受け取ったエラーを比較することで、何かが存在するかどうかを識別できます。特に決意のある攻撃者は、（特定の長さで）すべてのドキュメント名を列挙して、存在するものを確認する可能性があります。

さて、検証には複数のタイプがあります。

1. 要求が明らかに不正な形式ではないことを検証する安価な基本的な健全性チェック。

   これは通常、無駄な往復を避けるために、少なくとも部分的にクライアント側で複製されます。

   とにかく、情報漏えいのリスクがないため、物事を簡単にし、エラーを起こしにくくするために、アクセス制御の前に行う必要があります。

2. 保護されたアプリケーションデータに依存しない、より高価な検証。

   このような余分な検証がある場合は、データの漏洩を避けるためではなく、DOS攻撃を妨げるために、アクセス制御の後である可能性があります。
   リクエストを実行するだけで、その検証の一部が暗黙的に低コストまたは無料で実行される場合があるため、ここでは省略します。

   最初のステップのすべての検証が複製される場合、このクライアント側の部分も複製することは理にかなっているかもしれません。

3. 保護されたアプリケーションデータに応じた追加の検証。

   アクセス制御の前にそれを行うと、明らかに情報漏えいのリスクがあります。したがって、最初にアクセス制御を行います。

アクセス制御の前にいくつかの検証が必要です。SOのAPIにはエンドポイント「回答の編集」があり、ユーザーが特定の回答を編集できるかどうかは回答に依存するとします（特定の評判の下では、ユーザーは自分の回答のみを編集できます）。したがって、アクセスコントロールレイヤーが機能する前に、整形式の「応答ID」パラメーターを検証する必要があります。おそらく答えが存在することも。

CalethとGregが言及しているように、アクセス制御の前により広範な検証を行うOTOHは、潜在的なセキュリティリスクです。

厳しいルールは

1. ユーザーが他の方法で見つけることができないはずであるという検証を通じて情報を開示してはなりません。
2. アクセス制御が必要とする範囲でアクセス制御が使用できるようにするには、データを検証する必要があります。

これらの両方のルールに従うことは、アクセス制御の前と後にいくつかの検証が必要になることを意味する場合があります。

入力を検証した後に「アクセス拒否」を受信するというフラストレーションに加えて、また、Validationレイヤーは、非常にシンプルなものでない限り、常にControllerからの情報を必要とする可能性があることに注意してください。これを念頭に置いて、ValidationをAccess Controlの背後に配置し、Controllerの近くに置く方が理にかなっていると思います。

それは検証レイヤーの意味に依存します-もしリクエストの構文をチェックするだけなら、それは安全で、とにかくやらなければならないことです。「検証」で非特権ユーザーがアクセスできない情報を使用すると、安全ではなくなります。

アクセス制御を試みる前に、間違いなく健全性チェッカーを持っている必要がありますが、この部分が特権情報を使用してはならないことをすべてのメンテナー（現在および将来）に明確に伝えるよう注意してください。そのようなチェックは、認証後、別の検証手順で実行する必要があります。

健全性チェッカーの健全性チェックとして、パイプラインの下位のコードのどの部分にもコード依存性を実際に持たせてはならず、問題なく公開できるはずの独自のパッケージに分離する必要があります（法的な問題以外） 。それができない場合、「検証レイヤー」がやりすぎです（またはコードベースが混乱しています）。

いいえ。大丈夫ではありません。

検証レイヤーにバグがある場合、セキュリティレイヤーをバイパスする可能性があります。

ビジネス要件の一部としてセキュリティを考慮することはよくある間違いです。「役割がsalesのユーザーのみが四半期ごとの数値を見ることができるはずです」はビジネスルールのようです。

しかし、セキュリティを確保したい場合は、「セールスロールのユーザーのみ、このエンドポイントでコードを実行できるようにする」などのルールを読む必要があります。サーバーは、アクセスする前に常に「アクセス拒否」を返すようにします。作成したあらゆる種類のコードまたはサーバー上のファイル。