玄魂工作室

摘要： Windows Communication Foundation (WCF) 身份验证服务使你能够使用ASP.NET成员资格，从可以发送和使用SOAP消息的任何应用程序中对用户进行身份验证。这可以包括不使用.NET Framework的应用程序。因此，这些不同的应用程序的用户不需要对每个应用程序使用单独的凭据。用户在使用任意客户端应用程序时，均可通过提供相同的凭据登录到应用程序中。本节就使用WCF身份验证服务的几个关键点做实践性分析。 阅读全文

摘要： 通过前文共同体验了强名称对程序集的保护方式和原理，但是这种保护的强度到底有多大呢？能有效地防御恶意篡改者吗？先看下面的例子。 回到上篇文章的代码清单9-7，重新对StrongNameReferenceLib项目进行强名称签名，然后编译StrongName项目。在StrongName项目的bin目录里有StrongNam.exe和StrongNameReferenceLib.dll两个文件，然后使用ILDasm打开StrongNameReferenceLib.dll文件，转储为il文件，这里使用记事本打开il文件，如图9-19所示。 阅读全文

摘要： 引用强名称程序集的过程对我们来说都是透明的，无需做额外的工作。可以通过这种方式来检验强名称程序集的作用。 首先创建一个类库项目StrongNameReferenceLib，对其进行强名称签名。 阅读全文

摘要： 强名称是由程序集的标识加上公钥和数字签名组成的。其中，程序集的标识包括简单文本名称、版本号和区域性信息（如果提供的话）。强名称是使用相应的私钥，通过程序集文件（包含程序集清单的文件，并因而也包含构成该程序集的所有文件的名称和散列）生成的。Microsoft® Visual Studio® .NET 和在 .NET Framework SDK 中提供的其他开发工具能够将强名称分配给一个程序集。强名称相同的程序集应该是相同的。 通过签发具有强名称的程序集可以确保名称的全局唯一性。强名称满足以下要求： 1) 强名称依赖于唯一的密钥对来确保名称的唯一性。程序集名称不会与任何其他程序集名称相同，因为用一个私钥生成的程序集的名称与用其他私钥生成的程序集的名称不相同。 2) 强名称保护程序集的版本沿袭。强名称可以确保没有人能够生成程序集的后续版本。用户可以确信，他们所加 阅读全文

摘要： 在ASP.NET、SQL Server、WCF等通信领域，微软都提供了基于SSL的安全保护机制。遗憾的是，.NET并没有对SSL协议本身提供像TCP、UDP这样的基础网络协议的编程性支持。如果想从协议的角度处理SSL通信或者想构建完整的SSL框架，那么.NET帮不上你，但是还有选择，许多第三方安全通信的项目提供了支持，比如OpenSSL。这不意味着我们在此领域将无所作为，第6章介绍了.NET中操作数字证书的两个类： q System.Security.Cryptography.X509Certificates.X509Certificate2类 q System.Security.Cryptography.X509Certificates.X509Store类 在Web开发中，SSL通信由浏览器和Web服务器来实现通信细节。封装了HTTP协议的WebRequest、WebResp 阅读全文

摘要： HTTPS（Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即在HTTP下加入SSL层，HTTPS的安全基础是SSL。它是一个URI scheme（抽象标识符体系），句法类同“http:体系”。用于安全的HTTP数据传输。“https:URL”表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。简单的HTTPS通信过程如图所示。 阅读全文

摘要： 事实上各位读者已经明白了SSL的工作原理，回顾我前面博客讲到的公钥加密的通信原理，而SSL使用的就是公钥加密系统。现在完全可以构想基于SSL的数据通信流程。前面说过，SSL是一种协议，本节重点在于协议本身和它是如何工作在各种协议之间来提供安全通信的。 SSL协议位于TCP/IP协议模型的网络层和应用层之间,使用TCP来提供一种可靠的端到端的安全服务,它使客户/服务器应用之间的通信不被攻击窃听,并且始终对服务器进行认证,还可以选择对客户进行认证。SSL协议在应用层通信之前就已经完成加密算法、通信密钥的协商，以及服务器认证工作,在此之后,应用层协议所传送的数据都被加密。 阅读全文

摘要： 到目前为止，只是讨论了访问控制规则，它们构成了对象的DACL。DACL可以由对象的所有者任意更改，还可以由所有者已经给予其更改DACL权限的任何人更改。对象的安全描述符包含另一个规则列表，称为系统访问控制列表（System Access Control List，SACL），该列表将控制系统对对象执行哪个类型的审核。 审核是一种具有安全敏感性的操作。在Windows中，审核只能由本地安全机构（Local Security Authority，LSA）生成，因为LSA是唯一允许向安全事件日志（这里存储了审核）中写入项的组件。安全审核是一项非常严谨的业务，可以在计算机法庭中根据事实分析谁做了什么事情，以及谁试图在系统中做什么事情。很多组织都长年保留它们的审核日志。不用说，规定对哪些项目进行审核的设置通常都受到严格的管理控制。如果执行该节中的代码并且遇到UnauthorizedAccessExcept 阅读全文

摘要： 为方便起见，访问规则被公开为集合。该集合是只读的，因此对它的规则进行的所有修改都必须通过FileSecurity对象的专用方法（例如AddAccessRule、SetAccessRule和RemoveAccessRule）执行。集合内部的规则对象也是不可改变的。要了解为什么拒绝规则优先于允许规则，必须知道访问检查算法是如何工作的。当执行访问权限检查时，将按照规则在访问控制列表内部出现的顺序对它们进行评估。在代码清单7-11中，当检查用户Xuanhun的访问权限时，会首先评估拒绝Xuanhun读取访问的规则，然后再评估授予BUILTIN\Everyone读取和执行访问权限的规则。一旦做出允许或拒绝的决策，评估就将停止。这就是拒绝规则“生效”的原因。如果它们被放置在允许规则之后，则它们不会总是执行它们的预期功能。 和可以添加新的访问规则一样，还可以移除现有的访问规则。但是注意，在从用户那里撤回某项权 阅读全文

摘要： 如何在创建文件的初始就分配权限呢？这样做有一个重要的安全原因：可确保安全的对象总是用一些默认的安全语义创建的。默认情况下，分层式资源管理器（例如文件系统或注册表）中的对象从其父对象中继承它们的安全设置，文件从它们的父目录中继承它们的安全设置。默认权利取决于所创建对象的类型，而且可能不是您所希望的那样。例如，您很少会有意创建每个人都具有完全访问权限的对象，但这却可能恰好是默认安全设置所指定的权限。不能简单地用默认安全设置创建对象并且在以后修改这些设置，产生此问题的原因是：在已经创建对象之后对其加以保护会打开一个机会窗口（在创建和修改之间），在此期间，该对象可能被劫持。劫持可能导致创建者失去对刚刚所创建对象的控制，这会造成灾难性的后果。代码清单7-10演示了在如何创建文件时配置访问规则。 阅读全文