5

私の典型的なアプリでは、ユーザーは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
4

6 に答える 6

3

実装の観点からは、保護を必要とする関数の数が最も少なく、したがって混乱するものの数が最も少なく、すべてのユーザー入力に合格する必要があるため、スタックのできるだけ下にチェックを実装することが最善のソリューションです。保護されたレイヤーを介して。基盤が保護されている場合は、その基盤上に構築されているすべてのものを気にする必要はありません。

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

インターフェイスベースのプログラミングを使用する場合、アプリケーションレイヤー間で検証コードを共有できるため、これはまったく問題ありません。これにより、すべてのアプリケーション層に検証コードをさらに簡単に追加でき、多層防御が可能になります。あるアプリケーション層のバグが別の層によって検出される可能性があります。もちろん、検証コード自体に誤りがあり、それをアプリケーションレイヤー間で共有する場合、バグとハンスエラーはおそらくすべてのアプリケーションレイヤーに波及します。

于 2009-06-26T19:48:31.813 に答える
3

私の意見では、できるだけデータに近づける必要があります。データに近ければ近いほど、アクセスチェックを回避するためにコードベースを経由する遠回りのルートをたどることができないようにすることができます。

その引数は、データソース自体（お気に入りのRDBMSなど）またはデータアクセス層のいずれかにセキュリティチェックを配置することを要求します。

ただし、一部のセキュリティ制約には、ビジネスロジックの強い匂いがあります。たとえば、「ユーザーがこの役割を担っており、これらの仕様を満たすデータを変更しようとしている場合は、操作を許可する必要があります。それ以外の場合は許可しないでください」。それは私にはポリシーのように聞こえますが、ある種の別のルールエンジンのビジネスロジック層に属するものです。

少し前に、WCFのコンテキストで同様のことについて書きました。

于 2009-06-26T19:51:34.443 に答える
2

潜在的に危険で機密性の高いものを実際に実行するビジネスオブジェクトにロールアクセスチェックを配置します。

ページの読み込みとボタンのクリックイベントに役割チェックを追加することは、私見では無関係です。さらに、ページを保護する場合は、web.configの宣言型の場所ディレクティブを使用してページを保護します...たとえば、すべての「admin」ページを別のフォルダーに配置し、フォルダー全体を宣言的に保護します。

ただし、少なくとも、ビジネスオブジェクトメソッドを常にチェックする必要があります。

于 2009-06-26T19:17:12.160 に答える
2

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

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

したがって、Page_Loadに配置するだけでは不十分です。また、 PrincipalPermissionAttributeを使用してメソッドを装飾することも確認する必要があります。これにより、多くのコードが削減されます。

于 2009-06-26T19:22:32.087 に答える
2

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

于 2009-06-26T19:47:29.960 に答える
1

ビジネスオブジェクト。

しかし、建設時に。各インスタンスに非常に特定の役割をキャプチャさせます。

編集：この方法でより簡潔に。

于 2009-06-26T19:30:01.337 に答える