コールスタック内のどこでロールチェックが行われるべきですか？

Question

私の典型的なアプリケーションでは、ユーザーはaspxページ内のボタンをクリックし、C＃ビジネスオブジェクトを呼び出してからストアドプロシージャを実行します。

ロールチェックは、スタックの最上部、スタックの最下部、またはすべてのレベルで行う必要がありますか？悪意のあるユーザーが1つのメソッドを呼び出せば、任意のメソッドを呼び出すことができます。そのため、効果的なセキュリティを実現するには、すべてのメソッドをチェックする必要があります（書き込みには余分なコードがたくさんあります）。

Page_Load() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    AddAccount.Visible =true; 
    } 
} 

AddAccount_OnClick() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    //Add the account 
    Account.Add(...); //and maybe another role check... 
    } 
} 

-- TSQL doesn't understand .NET authorization, this call is in a 'trusted' subsystem 
create proc Add_Account @user, @account_name 
If @user in (Select user from role_table where role='manager') 
-- Add the account 

Answer 1

私の意見では、可能な限りデータに近づけるべきです。データに近ければ近いほど、アクセスチェックを回避するために、コードベースを経由して途切れるルートを取ることができないようにすることができます。

この引数は、セキュリティチェックがデータソース自体（サポートされているRDBMSなど）またはデータアクセス層のいずれかに配置されるように要求します。

しかし、セキュリティ制約の中にはビジネスロジックの強い匂いがあるものもあります。例えばユーザーがこの役割を果たしており、これらの仕様を満たすデータを変更しようとすると、その操作は許可されなければなりません。それは、ポリシーと、別のルールエンジンのビジネスロジックレイヤに属するもののようなものです。

I wrote about something similar in the context of WCF some time ago。

Answer 2

私は実際に潜在的に危険/敏感なものを実行し、ビジネス・オブジェクトでの役割のアクセスチェックを置きます：

は、ここに私の質問を説明するための典型的なコールスタックです。

ページのロードとボタンのクリックイベントにロールチェックを追加することは、IMHOとは関係ありません。また、ページを保護する場合は、web.config ...の宣言的な場所指示文を使用してページを保護してください。すべての "管理"ページを別のフォルダに入れ、宣言的にフォルダ全体を保護します。

ただし、ビジネスオブジェクトのメソッドについては、常にチェックする必要があります。

Answer 3

メソッドレベルに配置する必要があります。あなたは特定の方法でその方法に到達すると想定することはできません。このメソッドは、ボタンハンドラで呼び出すことも、任意のタイプのロジックの結果として通常のコードで呼び出すこともできます。何回このボタンハンドラを呼び出すようなものを見たことがありますか？

private void MyBypassingCall() 
{ 
    if(myLogic) 
    { 
    AddAccount_OnClick(); 
    } 
} 

Page_Loadに置くだけでは不十分です。また、PrincipalPermissionAttributeでメソッドを飾るチェックアウトする必要があります。これは多くのコードを削減します。

Answer 4

ビジネスオブジェクト。

しかし、建設時。各インスタンスが非常に具体的な役割を果たすようにします。

編集：このように簡潔になります。

Answer 5

これは、ビジネス側でセキュリティ検証を行うことがどれほど重要であるかという逸話的なコメントです。リクエストハッキングの期待が低いと楽観的ではなかった。私たちはビジネスオブジェクトにどんな種類の検証も行っておらず、予期しない方法で焼き付けられました。クライアントは、サイトの使用を自動化するスクリプトを作成しました。実際にはレンダリングされなかったスクリプト内の期待されるリンクに続いてしまいました。それはデータを破壊してしまった。もちろん、これはセキュリティ違反ではなく、システム状態やデータの完全性の問題ですが、どちらも本当に当てはまると思います。

Answer 6

実装の観点からは、保護を必要とする機能の数が最も少なく、したがって混乱する可能性の低いものが最も少ないため、できるだけスタックをはるかに下回るようにチェックを実装するのが最適なソリューションです。入力は保護されたレイヤーを通過する必要があります。あなたの財団が保護されている場合は、その財団のすべてを気にする必要はありません。

このソリューションには、1つの厄介な欠点があります。ユーザーインターフェイスには、認証、承認、データ検証などのすべてのことが分かっていません。したがって、すべての入力がスタックをダウンし、エラーが発生する可能性があります。また、スタックを上向きにしてユーザーに通知します。これにより、ユーザーインターフェイスで簡単に検出できるエラーは、データをバックエンドシステムに渡した後にのみ検出されるため、不快なユーザーエクスペリエンスが発生します。結果的に、より良いユーザーエクスペリエンスを提供するために、多くのチェックをユーザーインターフェイスに追加します。

インターフェイスベースのプログラミングを使用している場合は、アプリケーションレイヤ間で確認コードを共有できるので、これはまったく問題ありません。これにより、検証コードをすべてのアプリケーションレイヤに簡単に追加することができます。これにより、1つのアプリケーションレイヤのバグを別のレイヤで検出することができます。もちろん、検証コード自体に誤りがあり、それをアプリケーション層全体で共有すると、おそらくすべてのアプリケーション層でバグや不具合が発生する可能性があります。