摘要：在安装已管理代码或者未管理代码来确保安装本身是安全的时候，下列步骤是被建议的。并且这些步骤应该在所有支持 NTFS 文件系统的平台中被完成： 阅读全文

摘要：一些由 .NET Framework 所提供的许可而被保护的操作能够潜在地允许对安全系统产生回避。这些危险的许可只应该被提供给可依赖的代码，如果有必要的话。并且这样做通常不会防范任何反向的恶意代码，如果这些许可是被批准的。 阅读全文

摘要：一些库操作会通过产生代码并且运行它来为调用者完成一些操作。最基本的问题就是产生代表更少信任度的代码并且在拥有更高信任度的代码中来运行它。在调用者能够改变代码生成的时候，这个问题会继续得到恶化，因此你必须确保只有你认为是安全的代码才能够被生成。 阅读全文

摘要：另外一个所涉及的区域就是通过紊乱条件而潜在被利用的安全漏洞。这可能会出现几种方式，下面的子标题概述了开发者必须要避免的一些主要缺陷。 阅读全文

摘要：因为序列化能够允许其他的代码来查看或者更改不可以通过其他方式而被访问的对象实例数据，所以在完成代码序列化时所必需的一个特殊许可就是：被指定了 SerializationFormatter 标记的 SecurityPermission。在默认的策略之下，这个许可并没有提供给基于互联网的下载或者局域网中的代码；因此只有本地计算机中的代码才能够获得这个许可的批准。 阅读全文

摘要：要把代码隔离进被管理的托管环境中，通常的做法就是使用明确的策略（减少不同汇编集的许可等级）来产生多个子应用程序域。但是，这些汇编集策略在默认的应用程序域中仍然是不可改变的。如果子应用程序域中的任何一个能够强制默认的应用程序域来装载汇编集，那么就会失去代码隔离的作用并且在被强制装载的汇编集中的类型还能够运行拥有更高信任级别的代码。 阅读全文

摘要：一些对象自身会保持安全状态。并且这些对象也不应该被传递给未被信任的代码，然后获取除了它们自己的许可之外的安全授权。 阅读全文

摘要：远程允许你在应用程序域、进程，或者计算机之间来设置透明化的调用。但是，代码访问安全通道却无法跨越多个进程或者机器边界（它只在相同进程的应用程序域之间才适用）。 阅读全文

摘要：用户数据，就是任何种类的输入（来自于 Web 请求或者 URL 中的数据，输入在 Microsoft Windows 窗体应用程序的控件中的数据，等等），它能够对代码产生影响，因为这些数据经常被直接当成参数来使用并且用来调用其他的代码。这种情况类似于恶意代码以奇特的参数来调用你的代码，并且应该采取相应的措施来进行防范。然而，用户输入实际上更加难以安全化，因为并没有堆栈框架来追踪所出现的潜在的不被信任的数据。 阅读全文

摘要：在被管理的 C++ 扩展与 Visual Basic 中，过滤器表达式能够更进一步地让堆栈运行在任何 finally 声明之前。而与过滤器相关联的 catch 块则运行在 finally 声明之后。关于更多信息，请参考：［使用被用户过滤的异常］。本文只对这个次序的安全含义进行审查。考虑下列说明了在过滤器声明与 finally 声明中的运行次序的伪代码范例。 阅读全文

摘要：使用不从被管理的库中通过只读的公开的数组字段来定义边界行为或者定义你的应用程序的安全，因为只读的公开的数组字段能够被更改。 阅读全文

摘要：为未被管理的代码方法的命名而制定了一个有用的并且更具建议性的约定。所有未被管理的代码方法都被分散到了三个目录中：safe、native，以及 unsafe。这些关键字能够与被定义的不同种类的未被管理代码入口点的类名称一样被使用。在源代码中，这些关键字应该被添加到类的名称中（例如，Safe.GetTimeOfDay、Native.Xyz，或者 Unsafe.dangerousAPI）。每种关键字都为开发者对于类的使用而提供了有用的安全信息，与下表中被描述的一样。 阅读全文

摘要：声明然后调用未被管理的代码时存在一个性能问题。在每次被产生这种调用的时候，安全系统都会自动要求未被管理的代码许可，从而导致每次都会出现一个堆栈通道。如果你声明并且直接地调用了未被管理的代码，那么堆栈通道就可能是无意义的：因为它是由你的声明与你的未被管理代码的调用所组成。 阅读全文

摘要：有些库代码需要调用未被管理的代码，例如，本地代码 API（如 Win32）。因为这表示被管理的代码已经超出了安全范围之外，因此适当的谨慎是必需的。如果你的代码是属于安全中立的，那么你的代码与任何对它进行调用的代码都必须拥有未被管理的代码许可（指定了 UnmanagedCode 标记的 SecurityPermission）。 阅读全文

摘要：安全声明提供了两种类似的安全检查来完成不同的任务。你应该理解这两种形式，因为错误的选择能够削弱安全性或者损失性能。关于更多信息，请参考：［安全要求］。 阅读全文

摘要：一些方法被用来装载被管理代码，包括 Assembly.Load，它们会以调用者的意图来装载汇编集。如果你包装了这些方法中的任何一个，那么安全系统就会使用你的代码许可批准，替代对你的包装器进行调用的调用者许可来装载这些汇编集。所以你不应该允许几乎不被信任的代码来装载比你的包装器调用者拥有更高级别的代码。 阅读全文

摘要：连接要求的一种特殊的保护情况在安全机制中被加强，但是它在你的代码中仍然可能是一个弱点来源。 阅读全文

摘要：委派安全在不同的 .NET Framework 版本之间是有区别的。本文描述了不同的委派行为以及相关的安全考虑。 阅读全文

摘要：包装代码，尤其是比它的使用者拥有更高可信任度的包装代码，能够公开一个独特的安全弱点集。在调用者的被限制许可没有被包括在适当的安全检查中的时候，它会为调用者完成任何事情，并且也是一个潜在的可被利用的安全弱点。 阅读全文

摘要：在确定你的代码不可用于其他汇编集的时候，你就必须知道对于类型系统可访问性的细微差别。一个被声明成 virtual 或者 internal（在 Visual Basic 中是 Overloads Overridable Friend）的方法能够重载父类的虚表入口并且只能够在相同的汇编集中被使用，因为它是内嵌的。但是，重载的可访问性却能够通过 virtual 关键字而被检测，并且能够从另外一个汇编集中被重载，只要那个代码能够对类的本身进行访问。如果在实现重载时有可能会呈现出一个问题，那么就可以使用安全声明来修复它，或者是删除 virtual 关键字（如果它不是严格所必需的）。 阅读全文