5

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

角色检查应该在堆栈顶部、堆栈底部还是在每个级别进行？似乎如果恶意用户可以调用一个方法，他可以调用任何方法，因此为了有效的安全性，您需要检查每个方法（并且要编写很多额外的代码）。

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

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

从实现的角度来看，将检查实现尽可能远的堆栈将是最好的解决方案，因为需要保护的函数数量最少，因此要搞砸的事情最少，并且所有用户输入都必须通过通过保护层。如果您的基础受到保护，则您无需关心建立在该基础上的所有内容。

这个解决方案有一个明显的缺点——用户界面对身份验证、授权、数据验证和所有其他内容一无所知。因此，每个输入都会向下堆栈，可能会导致错误，然后再次向上堆栈以通知用户。这将导致不愉快的用户体验，因为在用户界面中很容易检测到的错误只有在将数据传递到后端系统后才能检测到。因此，您还将向用户界面添加许多检查，以提供更好的用户体验。

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

于 2009-06-26T19:48:31.813 回答
3

在我看来，你应该把它放在尽可能接近数据的地方。离数据越近，就越能确保不可能通过代码库采取迂回路线来规避访问检查。

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

但是，一些安全约束带有强烈的业务逻辑气味；例如，“如果用户处于此角色并试图修改符合这些规范的数据，则应允许该操作；否则不允许”。在我看来，这听起来像是一项策略，并且属于某种单独的规则引擎的业务逻辑层。

我前段时间在 WCF 的上下文中写过类似的东西。

于 2009-06-26T19:51:34.443 回答
2

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

恕我直言，将角色检查添加到页面加载和按钮单击事件将是无关紧要的。此外，如果您要保护页面，请使用 web.config 中的声明性位置指令保护页面……例如，将所有“管理”页面放在单独的文件夹中，并以声明方式保护整个文件夹。

但是，您至少应该始终检查您的业务对象方法。

于 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 回答