.net 角色检查应该在调用堆栈中的什么位置进行？

在我的典型应用程序中，用户单击aspx页面中的一个按钮，调用一个C#business对象，然后运行一个存储过程

角色检查应该在堆栈的顶部、底部还是在每个级别进行？看起来，如果恶意用户可以调用一个方法，那么他可以调用任何方法，因此为了有效的安全性，您需要对每个方法进行检查（这需要编写大量额外的代码）

下面是一个典型的调用堆栈来说明我的问题：

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

---

我会将角色访问检查放在实际执行潜在危险/敏感内容的业务对象中

IMHO表示，将角色检查添加到页面加载和按钮单击事件将是无关的。此外，如果要保护页面，请使用web.config中的声明性位置指令保护页面。。。e、 g.将所有“管理员”页面放在一个单独的文件夹中，并声明性地保护整个文件夹

---

但是，您至少应该对业务对象方法进行检查。

您需要将其置于方法级别。您不能假设您以任何特定的方式达到该方法。该方法可以由按钮处理程序调用，也可以作为任何类型逻辑的结果在普通代码中调用。你见过多少次这样的东西调用按钮处理程序

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

所以把它放在页面加载上是不够的。您还应该检查一下用一个。这减少了大量代码。

业务对象

但在施工时。让每个实例捕获一个非常特定的角色

---

编辑：这样更简洁。

这只是一个轶事评论，说明在业务方面进行安全验证是多么重要。在我们的案例中，对请求黑客的低期望值持乐观态度是不够的。我们的业务对象中没有任何类型的验证，因此被意外地烧掉了。一个客户构建了一个脚本来自动使用我们的站点。它最终遵循了脚本中实际未呈现的预期链接。它最终破坏了数据。当然，这对我们来说更像是一个系统状态和数据完整性问题，而不是一个安全漏洞，但我认为两者都适用。

从实现的角度来看，最好的解决方案是尽可能在堆栈的最底层实现检查，因为需要保护的功能数量最少，因此，需要处理的事情最少，所有用户输入都必须通过保护层。如果你的基金会受到保护，你不必担心所有的事情都是建立在这个基础上的。 这个解决方案有一个明显的缺点——用户界面对身份验证、授权、数据验证和所有其他内容一无所知。因此，每个输入都会进入堆栈，可能会导致错误，然后再次进入堆栈以通知用户。这将导致不愉快的用户体验，因为用户界面中容易检测到的错误只有在将数据传递到后端系统后才能检测到。因此，为了提供更好的用户体验，您还将向用户界面添加许多检查

---

如果您使用基于接口的编程，这一点都没有问题，因为您可以在应用程序层之间共享验证代码。这使您能够进一步轻松地向所有应用程序层添加验证代码，这将为您提供深度防御—一个应用程序层中的错误可能会被另一层捕获。当然，如果验证代码本身是错误的，并且您在不同的应用程序层之间共享它，那么bug和错误可能会在所有的应用程序层中出现。

在我看来，您应该将其尽可能靠近数据。您离数据越近，就越能确保不可能通过代码库迂回地绕过访问检查

该参数将要求在数据源本身（如果它支持它的话）（如您最喜欢的RDBMS）或数据访问层中进行安全检查

然而，一些安全约束具有强烈的业务逻辑气味；e、 g.“如果用户担任此角色并试图修改符合这些规范的数据，则应允许该操作；否则不允许”。对我来说，这听起来像是一个策略，属于某个单独规则引擎的业务逻辑层