特定のデータベースオブジェクトまたはレコードに対する権限のユーザーアクセスチェック

Question

ユーザーがログインしてWebアプリケーションのドキュメントにアクセスしている状況について、開発者と友好的な議論をしています。ユーザーが表示するドキュメントを読み込むと、セッションにuserIDがあり、QueryStringを介して渡されるdocumentIDがあります。

ユーザーがQueryStringのdocumentIDを変更できないようにするには、ドキュメントを読み込むストアドプロシージャが、ドキュメントに対する権限を検証するパラメーターとしてUserIdを取ることを提案します。

開発者の友人は、別のプロシージャを実行してページの前のドキュメントへのアクセス権を決定し、ドキュメントを表示する必要があるときにドキュメントを取得するプロシージャを実行することを提案しています。

何かが足りませんか？最も効率的で安全なのはどれですか？ DocIDを含むUserIdを1つのプロシージャコールに渡して権限を確認し、ドキュメントをプルする方が効率的なソリューションだと思いました。

Answer 1

厳密にはパフォーマンスの観点から、UserIDとDocumentIDを1つのストアドプロシージャに渡すのが最適です。データベースサーバーへの往復は1回のみです。また、他の人が指摘したように、他のページまたはアプリケーションからこのドキュメントを取得する場合、同じストアドプロシージャを使用する場合は、セキュリティをバイパスしないようにします。

ただし、専用のセキュリティ検証ストアドプロシージャを持つことが理にかなっているシナリオがあります。ドキュメント以外に保護したい他のリソースがあり、検証コードが簡単でない場合は、データベースのすべてのストアドプロシージャで検証コードを複製したくない場合があります。その場合、セキュリティインフラストラクチャをデータアクセスレイヤーに移動し、要求されたリソースを取得する前に、データアクセスレイヤーにdb呼び出しを行わせてアクセスを許可することをお勧めします。この方法を採用する場合、開発者に頼ってリソースを要求する前に必ず認証db呼び出しを行うことを忘れないでください。

Answer 2

  

ストアドプロシージャを提案します   文書をロードする   検証するパラメーターとしてのUserId   ドキュメントの権利。

これが進むべき道だと思います。それ以外の理由がなければ安全です。このprocを再利用し、アクセスの確認を忘れると、大きな穴が開いてしまいます。このように、アクセス権がない限りドキュメントにアクセスできないということは明らかであり、焼き付けられています。

Answer 3

userIDはセッション変数である必要があります。右。クエリ文字列でdocumentIDを渡します。うん。

ドキュメントがデータベースに保存されていると仮定すると、レコードID、ユーザーID、およびドキュメントIDのアクセス許可のテーブルがあります。文書を呼び出すときに、このテーブルと結合します。結果が得られない場合、ドキュメントは得られません。インデックスを作成すると、高速になります。