在调用堆栈中应该进行角色检查？

在我的典型应用中，用户单击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

来源

2009-06-26 MatthewMartin

在我看来，你应该尽可能接近数据。越接近数据，越能确保无法通过代码库来绕过访问检查的迂回路线。

该参数会要求安全检查放置在数据源本身（如果它支持它（如您最喜爱的RDBMS）或数据访问层）。

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

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

来源

2009-06-26 19:51:34

我会放在业务对象的角色访问检查实际执行有潜在危险的/敏感的东西。

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

但是，你应该始终有你的业务对象方法的检查，在最低限度。

来源

2009-06-26 19:17:12

您需要将它放在方法级别。你不能假设你以任何特定的方式达到该方法。该方法可以由按钮处理程序调用，也可以作为任何类型逻辑的结果在正常代码中调用。有多少次你看过像这样的东西叫一个按钮处理程序...

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

因此把它放在Page_Load上是不够的。您还应该检查装饰方法PrincipalPermissionAttribute。这减少了很多代码。

来源

2009-06-26 19:22:32

业务对象。

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

编辑：这个更简洁。

来源

2009-06-26 19:30:01 hythlodayr

这是它可以是多么的重要，做业务方面的安全验证只是一个传闻发表评论。在我们的案例中，对请求黑客的低期望感到乐观是不够的。我们在业务对象中没有任何验证，并以意想不到的方式被烧毁。客户构建了一个脚本来自动化他们对我们网站的使用。它结束后，其脚本中的预期链接并未实际呈现。它最终破坏了数据。当然，这对我们来说更像是一个系统状态和数据完整性问题，而不是安全漏洞，但我想这两者都适用。

来源

2009-06-26 19:47:29

从实现的角度来看，这将是实现支票远了堆栈可能的，因为有那些需要保护，因此最低的一些事情搞糟功能编号最小的最佳解决方案，并且所有用户输入必须通过保护层。如果你的基金会受到保护，你就不必关心在这个基础上建立的一切。

这个方案有一个obviouse缺点 - 用户界面一无所知身份验证，授权，数据验证，以及所有其他的东西。因此，每个输入都会下入堆栈，可能会导致错误，并再次上传堆栈以通知用户。这会导致令人不快的用户体验，因为只有在将数据传递到后端系统后才能检测到在用户界面中容易检测到的错误。因此，您也将为用户界面添加许多检查，以便提供更好的用户体验。

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

来源

2009-06-26 19:48:31

在调用堆栈中应该进行角色检查？

回答

相关问题