因此我创建了一个CustomPermissionAttribute,应该如下所示使用:
[CustomPermissionAttribute(SecurityAction.Demand,Permission="PermMethodABC")] public void MethodABC() { }
Attribute的CreatePermission()方法创建并返回一个新的CustomPermission实例.
CustomPermission类的Demand方法应该检查Thread.Current.CurrentPrincipial中我的自定义IPrincipial实现的安全性:
public sealed class CustomPermission : IPermission { private string _requiredPermission; ... public void Demand() { ICustomPrincipial _pr = Thread.Current.CurrentPrincipial as ICustomPrincipial; if (_pr == null) throw... if (!_pr.HasPermission(_requiredPermission)) throw... } } public interface ICustomPrincipial : IPrincipial { bool HasPermission(string requiredPermission); }
以上所有内容均在签署的“A组”中.
未签名的程序集B包含以下CustomPrincipial实现,该实现实现程序集A的ICustomPrincipial:
public sealed class CustomPrincipial : ICustomPrincipial { User _User; ... public bool HasPermission(string requiredPermission) { if (_User has permission defined with "PermMethodABC") ... return true/false; } ... }
(现在程序集A必须知道有关用户类型的任何信息.如果我将CustomPrincipial类放入程序集A中,那么所有具有用户资料的程序集也必须进行签名…否则我无法编译程序集A)
在应用程序启动时,将为Thread.Current.CurrentPrincipial分配一个新的CustomPrincipial实例.
两个问题:
>可以安装程序集A中公共ICustomPermission接口引起的安全问题吗?
>完全实施所有IPermission会员是否绝对必要?特别是ToXML和FromXML方法……每次在运行时访问MethodABC()时,无论如何都会调用CreatePermission()方法.
编辑:
广告1:我正在考虑以下情况:“程序集C”包含受CustomPermissionAttribute保护的MethodXY.要访问此受保护的方法,攻击者可以创建一个新的应用程序,对程序集A和A的引用.程序集C可以自己实现程序集A的公共ICustomPrincipial接口( – > HasPermission()一直返回true).他可以将他的实现实例分配给他自己的Thread.Current.CurrentPrincipial.如果程序集A的Demand()方法检查Thread.Current.CurrentPrincipial,则攻击者可以访问MethodXY.那可能是一种可能的情况..!?
解决方法
Could saftey problems caused by the public ICustomPermission interface in Assembly A?
假设您对权限很小心,Thread.Current.CurrentPrincipal对大多数其他程序应该是只读的,这使得绕过不可能. (至少从MSDN页面快速浏览一下)
但是,与任何安全问题一样,最好自己测试一下.尝试编写在您的环境中运行的代码,并实现自己绕过CurrentPrincipal的方法.
Is it absolutely necessary to fully implement all IPermission Members? Especially the ToXML and FromXML Methods… The CreatePermission() Method gets anyway invoked everytime i access MethodABC() at runtime.
在完整实现的msdn页面上有一个示例,它看起来并不太令人讨厌,并且可以保证您以后不会因为NotImplementedException而出现问题.
但是,我没有对IPermission进行足够的实验来了解在正常操作期间调用哪些方法.
要记住的一个重要事项是,如果一段代码具有修改主体的权限,那么就没有太多可以阻止它绕过您的任何权限. SecurityPermissionFlag.ControlPrincipal是设置CurrentPrincipal需求的权限.我相信除非你使用像caspol.exe这样的工具,否则任何可执行文件都将在完全信任下运行.
总而言之,默认情况下,.NET框架假定自定义代码完全受信任,除非另有说明.如果您正在调用您不信任的代码,那么有机制可以确保代码以较低的安全凭证运行,或者如果您有可信任的可执行文件,则可以降低其安全凭据.但是,该计算机的任何管理员都有足够的能力绕过您实现的任何代码访问安全性(正如您对IPrincipal覆盖进行了评论).
如果这个解释不够好让我知道,我可以添加更多细节.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。