アクセス制御層の前に検証層があっても大丈夫ですか
私はAPI構造化Webアプリケーションを作成しています。このアプリケーションには、独自の仕事をしているさまざまなレイヤーがあります。
最初のレイヤーはValidationユーザー入力を検証するレイヤーであり、検証に合格した場合はそれを2番目のレイヤー（Access Control layer）に移動します。それ以外の場合はエラーメッセージを返します
2番目のレイヤーはAccess Controlで、ユーザーが実行したいタスクを実行する権限を持っているかどうかをチェックします。ユーザーが権限を持っている場合、リクエストを次のレイヤーに移動します。それ以外の場合はエラーメッセージを返します。
3番目のレイヤーはControllerアプリケーションのロジックがあるレイヤー
私の質問は、アクセス制御の前に検証レイヤーがあってもいいですか？ユーザーが権限を持たないタスクを実行しようとして、検証エラーメッセージを返送した場合はどうなりますか？ユーザーはエンドポイントにリクエストを送信し、検証レイヤーと通信します。検証に合格すると、メッセージYou can't access this!が表示されます
不思議に思うので、これでいいのですか、それともインフラストラクチャでこれ以外のオプションを選択できるのでしょうか。
許可されていないタスクの入力の妥当性を知っていることがセキュリティリークであるかどうかによって異なります。もしそうなら、あなたは本当にそれを逆に行うべきです。
権限のないユーザーへの唯一の安全な応答は、「アクセス拒否」です。応答が「不正な要求」である場合と「アクセス拒否」である場合は、権限のないユーザーに情報を送信しています。
例として、「ドキュメントの削除」タスクの検証で、指定されたドキュメントが存在することを確認できます。アクセス許可のないユーザーは、何かを削除しようとして、どのエラーが返されるかを比較することで、何かが存在するかどうかを識別できます。特に断固とした攻撃者は、（特定の長さの下で）すべてのドキュメント名を列挙して、どれが存在するかを確認する可能性があります。
まあ、検証には複数のタイプがあります：
安価な基本的な健全性チェック。リクエストが明らかに不正な形式ではないことを確認します。
これは通常、無駄なラウンドトリップを避けるために、少なくとも部分的にクライアント側で複製されます。
いずれにせよ、情報漏えいのリスクがないので、アクセス制御の前に行う必要があります。
保護されたアプリケーションデータに依存しない、より高価な検証。
そのような追加の検証がある場合、データの漏洩を回避せずにDOS攻撃を妨げるために、アクセス制御の後である可能性があります。
時には、リクエストを単に実行するだけで、その検証の一部が暗黙のうちにコスト削減またはコストなしで行われるため、ここでは省略される場合があります。最初のステップのすべての検証が重複している場合、このクライアント側の一部も複製することは理にかなっています。
保護されたアプリケーションデータに応じた追加の検証。
アクセス制御の前にそれを行うと、明らかに情報漏えいの危険があります。したがって、最初にアクセス制御を行います。
アクセス制御の前にsome検証が必要です。 SOのAPIに「回答の編集」というエンドポイントがあるとしましょう。ユーザーが特定の回答を編集できるかどうかは、回答に依存します（特定の評判の下では、ユーザーは自分の回答しか編集できません）。したがって、整形式の「応答ID」パラメーターは、アクセス制御層が機能する前に検証する必要があります。おそらくその答えが存在することも。
OTOHは、CalethとGregが述べているように、アクセス制御が潜在的なセキュリティリスクになる前に、より広範な検証を行います。
したがって、ハードルールは
- 検証を通じて、ユーザーが他の方法で見つけることができないはずの情報を開示してはなりません。
- アクセス制御が必要とする範囲でアクセス制御がデータを使用する前に、データを検証する必要があります。
これらの両方のルールに従うことは、アクセス制御の前後にいくつかの検証が必要になることを意味する場合があります。
「アクセスが拒否されました」を受け取ることによる不満の可能性に加えてafter入力を検証しています。 Validationレイヤーは、非常に単純なレイヤーでない限り、常にControllerからの情報が必要になる可能性があることにも注意してください。これを念頭に置いて、検証アクセス制御の後ろ、コントローラの近くに配置する方が理にかなっていると思います。
それは、検証レイヤーが何を意味するかによって異なります。つまり、リクエストの構文をチェックするだけの場合は、安全であり、とにかくやらなければならないことです。 「検証」で、権限のないユーザーがアクセスできないany情報を使用している場合、安全ではなくなります。
アクセス制御を試みる前に確実に健全性チェッカーを用意する必要がありますが、この部分はすべてのメンテナ（現在および将来）に非常に明確に伝えるように注意する必要があります不可特権情報を使用します。このようなチェックは、別の検証ステップafter認証で行う必要があります。
健全性チェッカーの健全性チェックとして、実際にはコードのどの部分にもコードの依存関係がなく、パイプラインの下位にある必要があり、独自のパッケージに分離可能で、問題なく公開できる（法的な問題以外）必要があります。 。それができない場合は、「検証レイヤー」が多すぎます（またはコードベースが混乱しています）。
いいえ、大丈夫ではありません。
検証層にバグがある場合、セキュリティ層をバイパスする可能性があります。
セキュリティをビジネス要件の一部と見なすのはよくある間違いです。 「役割がsalesのユーザーのみが四半期ごとの数値を見ることができるはずです」というのはビジネスルールのようです。
ただし、セキュリティで保護する場合は、「salesロールのユーザーのみが、このエンドポイントでコードを実行できるようにする必要があります」などのルールを読み取る必要があります。あなたが書いたあらゆる種類のコードまたはサーバー上のファイル。