下载掌阅APP，畅读海量书库
立即打开
2.2 System.Security
System.Security提供公共语言运行类库安全系统的基础结构，其中包括定义所有代码访问权限的基础类CodeAccessPermission。该基础类不能直接使用，开发人员需要赋予代码特别的权限来访问指定的资源，如使用FileIOPermission赋予代码权限来完成公文的I/O操作，使用EventLogPermission赋予代码访问操作系统日志的权限等。
System.Security命名空间也包括一些设置权限信息的基础类，主要包括PermissionSet和NamedPermissionSet。
在处理Web系统的出错信息环节上，开发人员可以利用安全信息处理类SecurityException。该类用于保密系统的安全错误处理，防止它们落入黑客之手。
目前很多木马都是通过文件的方式注入到正在运行的Web系统。下面两个实例将告诉读者如何加固Web系统的文件上传功能和安全日志功能。
FileIOPermissionAccess提供下列4种文件I/O访问权限类型：
（1）Read：对文件内容的读权限或对有关该文件的信息（如它的长度或上次修改时间）的读权限。
（2）Write：对文件内容的写权限或更改有关该文件信息的写权限，同时还允许删除和改写。
（3）Append：仅向文件结尾写入的能力，不能读取。
（4）PathDiscovery：对路径本身信息的访问权限。这可以保护路径中的敏感信息（如用户名）以及有关路径中显示的目录结构信息。此类型不授予对路径所指代的文件或文件夹的访问权限。
假设这时用户需要读取服务器上D盘下的IOtest.doc文件，则需要检测当前进程的权限后再决定是否执行该读写操作。实现代码如下：
需要注意的是，FileIOPermission.Demand()执行这一权限的检测工作，遍历此方法调用链上的所有组件，检测他们是否有读写权限。
开发人员把系统安全日志信息存放到数据库或者系统运行目录下的做法是不安全的。
为了确保包括敏感数据和错误数据的文件不被黑客获取，最安全的方法就是将它们存放到服务器安全日志。但请读者注意，日志代码如果设计于单个的程序集中，则不能利用该代码来阅读现有记录或删除事件日志。这种情况下应该解决的主要威胁是，如何阻止恶意调用方在一次尝试中多次调用代码，强制日志文件循环覆盖以前的日志条目来隐匿踪迹。解决这个问题的最好办法是使用出界机制，如只要事件日志一达到阈值就向操作员发出警报。
EventLogPermission类实现对事件日志服务的读或写访问，访问事件日志必须使用代码访问安全性策略为程序集授予属性 EventLogPermission。
当需要制约事件日志代码的权限，则需要由开发人员声明属性SecurityAction.PermitOnly。该属性可以确保WriteToLog方法及其调用的其他方法只能访问本地计算机的事件日志，而无法删除事件日志或事件源，实例代码如下：
当Web系统的日志代码位于程序集时，则需要确保在没有给代码授予充分的日志访问权限前无法加载程序集，应添加带SecurityAction.RequestMinimum的程序集访问属性EventLogPermissionAttribute，实例代码如下：
上述情况是针对Web托管代码而言的，而对于使用C++/C编写的组件或应用程序，则需要有选择性的控制它们的访问权限。在System.Security空间，SupressUnmanaged SecurityAttribute用来控制非托管代码的访问权限。当托管代码调入非托管代码（通过PInvoke或COM Interop进入本机代码）和程序编译链接时，均要求UnmanagedCode权限以确保所有调用方都有允许调入的必要权限。例如，函数A调用函数B，并且函数B用SuppressUnmanagedCodeSecurityAttribute进行了标记，则在实时编译时检查函数A的非托管代码权限，但随后在运行时不进行检查，因此使用此属性应特别小心，否则会产生安全漏洞。