
使用Python调用免费归属地查询API
.NET Framework 是 Microsoft 的主要企业开发平台。它包含一组用于开发桌面、服务器和 Web 应用程序的 API。它的起源可以追溯到 2002 年,当时是 Windows 的专有框架。但从那时起,它就变成了适用于 Windows、Linux 和 macOS 的免费开源框架。
.Net 框架已经存在很长时间了,并且是目前使用最广泛的操作系统之一的企业框架。因此,它也有自己的漏洞。但微软和开源社区为该框架提供了出色的支持。因此,您可以遵循微软的指导方针并采用与任何编程框架相同的最佳实践来编写安全的应用程序。
让我们看看 .Net 的安全功能、一些针对 .Net 开发人员的最佳实践,以及该框架如何抵御一些最常见的安全威胁。
当托管代码在 Windows 上的 .Net 下运行时,它可以访问 Windows 的身份和主体子系统。因此,在 Windows 上运行的 .Net 应用程序可以访问 Windows 安全性和基于角色的访问控制。但是,.Net Core 对 Linux 和 macOS 上的用户和身份验证资源的访问级别不同。因此,跨平台应用程序需要一些额外的身份验证帮助。
.Net Core 确实拥有IAuthentication 服务。应用程序可以使用它来访问第三方身份验证服务,例如 Twitter、Google 和内部 OAuth 服务。在所有情况下,使用 .Net 框架对用户进行身份验证都会创建一个 Principal 对象,该对象对于基于角色的安全性等操作很有用。
如果您使用 .Net 的身份验证服务,您也可以访问基于角色的访问控制 (RBAC)。.Net 框架内置了对RBAC 的支持。如果使用得当,RBAC 将保护应用程序免受许多常见攻击。拥有支持并不会自动使 .Net 安全,但内置行为意味着您不必自己编写它,并且该功能已经过尝试和测试。
.Net 编译器将代码编译为 Microsoft 中间语言 (MSIL) 以供分发。然后,即时编译器在执行时将其编译为本机代码。
将 MSIL 编译为本机代码的一部分是检查代码及其相关元数据的验证过程。微软令人困惑地将此检查称为“类型安全”,尽管它与编程语言中强制执行的类型安全无关。
MSIL 代码只能访问授权的内存位置。这可确保模块之间正确隔离,并验证运行时是否可以强制执行安全限制。
系统管理员可以根据特定代码段或整个系统覆盖此验证步骤。但是,这几乎不是一个好主意。
我们的第一个最佳实践建议是不要覆盖上面概述的“类型安全”验证检查。虽然此检查并不完美,甚至在极少数情况下有效代码也可能无法通过检查,但运行不受信任的代码永远不是一个好主意。对Nuget等系统的供应链攻击使运行未经测试和未经验证的代码变得过于危险。
如果必须运行不受信任的代码,请采取额外的安全措施,例如在隔离不安全代码的容器或虚拟环境中运行应用程序。
如果您没有仔细验证和清理用户输入,则可能会导致您的应用程序出现问题。虽然 .Net 具有验证调用您的应用程序或库的代码的机制,但当涉及到用户指定的信息时,您只能靠自己了。
以下是您应该针对用户数据进行的检查的简要列表:
下面我们将研究的所有常见攻击都涉及恶意输入。
验证和清理用户输入是您可以采取的最重要的安全预防措施之一。
.Net 拥有成熟而强大的软件包生态系统。这让您可以轻松地使用Nuget保持依赖项的更新。将检查更新作为维护的一部分。然后,作为常规发布过程的一部分,使用新库重建和测试您的代码。
最后,让我们总结一下四种最常见的 .Net 安全威胁。
SQL 注入攻击是指恶意攻击者利用未正确清理输入的应用程序。攻击者通过强制应用程序执行 SQL 语句来利用此弱点。这是一种非常现实的威胁,编码不当的 .Net 应用程序很容易受到攻击。
XSS 是另一种注入攻击。攻击者通过将有害脚本注入为(您猜对了)恶意输入,诱骗网站运行有害脚本,从而发生此类攻击。XSS 攻击通常利用<script>标签,希望网站接受并运行该脚本。
跨站请求伪造听起来有些拗口,但其名称已经说明了它到底是什么。当来自恶意网站的伪造请求诱骗经过身份验证的用户运行有害代码时,就会发生这种情况。这种攻击依赖于用户登录并有权访问特权信息或资源,例如信用卡号或银行账户访问权限。
一旦这种攻击得逞,后果将不堪设想。点击此处了解有关 CSRF 的更多信息以及如何保护您的 .Net 代码免受其侵害。
XML 外部实体攻击利用了应用程序处理 XML 时的漏洞。这是另一种注入攻击。XML 文档包含可让应用程序轻松访问外部数据的构造。但是,这些机制落入坏人之手会非常危险。因此,攻击者可以诱骗应用程序从其他站点下载恶意代码。或者,它可以诱骗服务器提供敏感信息。更糟糕的是,精心制作的文档可以通过导致服务器崩溃来充当拒绝服务攻击。