乐趣区

关于c#:ASPNET-Core中的数据保护

在这篇文章中,我将介绍 ASP.NET Core 数据保护零碎: 它是什么,为什么咱们须要它,以及它如何工作。

为什么咱们须要数据保护零碎?

数据保护零碎是 ASP.NET Core 应用的一组加密 api。加密必须由不受信赖的第三方解决的数据。

这方面的典型例子是身份验证 cookie。cookie 是在申请之间长久化状态的一种办法。你不心愿每次向服务器申请时都必须提供用户名和明码,这将十分麻烦!

相同,只需向服务器提供一次凭据。服务器验证你的详细信息,并收回一个 cookie,表明“他不须要提供任何其余证实,置信他。”对于后续的申请,能够简略地提供该 cookie,而不用提供凭据。浏览器主动发送 cookie 与后续申请,这是 web 为用户实现晦涩登录体验的形式。

cookie 是十分敏感的货色。任何蕴含 cookie 的申请都将被视为原始用户发送的申请,就像原始用户在每个申请中都提供了用户名和明码一样。浏览器中有很多保护措施 (例如 CORS) 来阻止攻击者拜访这些 cookie。

然而,这不仅仅是阻止他人失去你的 cookie。作为一个网站所有者,你也不心愿用户篡改他们本人的 cookie。

身份验证 cookie 通常不仅仅蕴含通过身份验证的用户的 ID 或名称。它们通常蕴含各种附加的要求。它蕴含了用户的详细信息。它们能够是实在数据,如名称、电子邮件或电话号码,但它们也能够是与权限相干的申明,如是否是管理员或是否能够编辑。

对于每个申请,通常都须要这些,以确定是否容许用户采取操作。通常蕴含在发送给用户的身份验证 cookie 中,而不是每次申请都必须从数据库加载。

这使得应用程序更加容易——一旦通过从 cookie 中提取用户主体对用户进行身份验证,应用程序就会确切地晓得用户领有哪些权限。这意味着应用程序必须信赖 cookie。如果 cookie 是明文发送的,那么用户只需编辑这些值,就会裸露应用程序中显著的安全漏洞。

ASP.NET Core 数据保护零碎正是为了这个目标而应用的。它对敏感数据 (如身份验证 cookie) 进行加密和解密。通过在响应中返回身份验证 cookie 之前对其进行加密,应用程序晓得该 cookie 没有被篡改,并能够信赖其值。

数据保护零碎如何工作?

数据保护零碎试图解决一个辣手的问题: 如何爱护裸露给攻击者的敏感数据,现实状况下不向开发人员裸露任何密钥,同时遵循加密的最佳实际。

数据保护零碎应用对称密钥加密来爱护数据。应用蕴含随机数据的密钥加密数据,应用雷同的密钥解密数据。

在一个典型的 ASP.NET Core 应用程序可能有几种不同类型的不相干数据须要加密。例如,除了身份验证 cookie 之外,可能还须要加密跨站点申请伪造令牌 (CSRF) 或明码重置令牌。

你能够将雷同的键用于所有这些不同的目标,但这可能会带来问题。例如,如果明码重置令牌不能“意外地”(更有可能是歹意地)用作身份验证令牌,那就好得多。

ASP.NET Core 数据保护零碎实现了这一指标。数据保护零碎有一个不能间接应用的父密钥。必须从父密钥派生子密钥,这些子密钥用于加密和解密数据。

应用雷同的 purpose 字符串从父密钥派生密钥总是会给出雷同的密钥,因而如果你领有父密钥并且晓得 purpose 字符串,那么总是能够解密已加密的数据。如果密钥是用不同的 purpose 导出的,那么尝试解密数据将会失败。这样能够保持数据隔离,这对安全性更好。

在大多数状况下,你不用间接与数据保护零碎交互来创立密钥或加密数据。这是由 ASP.NET Core 外围框架及其附带的库解决的。它们确保在你的应用程序中为每个不同的 purpose 应用惟一的字符串。如果你违心,你能够创立本人的爱护程序并加密其余数据(见下文),但这不是 ASP.NET Core 的日常运行所必须的。

我是一个.net 框架开发者——这听起来很像 <machineKey>?

数据保护零碎是 ASP.NET Core 的一个新性能。,然而爱护身份验证令牌的须要并不是新的,那么咱们以前用的是什么呢? 答案是 <machineKey>。<machineKey> 元素的应用形式与 ASP.NET Core 数据保护零碎十分类似,配置密钥和密码学套件,用于通过身份验证零碎加密数据(以及其余中央)。可怜的是,应用这个密钥时有些简单,因为它通常是从__machine.config__读取的。必须在运行应用程序的机器上配置。在集群中运行时,必须确保这些键放弃同步,否则可能会产生问题!

在.net Framework 4.5 中,咱们能够替换 <machineKey> 元素及其应用的整个加密管道。

如何治理数据保护密钥?

如果对安全性有所理解,那么你可能曾经听到应该定期轮换明码、秘密和证书的说法。如果你的某个机密被泄露了,这能够在肯定水平上缩小影响。这就是为什么签发 HTTPS 证书的寿命越来越短的起因。

依据你从框架和工具取得的反对,更换秘钥和证书可能会很苦楚,特地是在过渡时期,可能须要同时反对新旧秘钥。

鉴于数据保护对于爱护 ASP.NET Core 是至关重要的。你不会诧异秘钥轮换是数据保护零碎的默认设置。默认状况下,数据保护的生命周期为 90 天,但通常不用为此放心。当旧密钥快要过期时,数据保护零碎会主动创立新的密钥。所有可用密钥的汇合称为密匙环。

在这篇文章中,我不会深刻密钥治理的细节。请留神,秘钥轮换是主动产生的,只有你不删除任何旧的键(或显式地撤销它们),那么加密的数据依然能够应用过期的键检索。过期的密钥不能用于加密新数据。

我是否也能够爱护其余数据,还是仅用于身份验证 cookie?

数据保护零碎由 ASP.NET Core 隐含地应用并解决认证令牌的加密和解密。它也被 ASP.NET Core 用来爱护明码重置和 MFA 令牌。你不须要为这种爱护做任何事件——框架本人解决爱护。

如果你有本人想要加密的长期数据,能够间接应用数据保护 api。我将在前面的文章中具体介绍,但以下内容展现了中如何应用 IDataProtectionProvider 服务 (默认在 ASP.NET Core apps) 加密和解密一些数据:

public class MyClass
{
    // The IDataProtectionProvider is registered by default in ASP.NET Core
    readonly IDataProtectionProvider _rootProvider;
    public MyClass(IDataProtectionProvider rootProvider)
    {_rootProvider = rootProvider;}

    public void RunSample()
    {
        // Create a child key using the purpose string
        string purpose = "Contoso.MyClass.v1";
        IDataProtector protector = provider.CreateProtector(purpose);

        // Get the data to protect
        Console.Write("Enter input:");
        string input = Console.ReadLine();
        // Enter input: Hello world!

        // protect the payload
        string protectedPayload = _protector.Protect(input);
        Console.WriteLine($"Protect returned: {protectedPayload}");
        //PRINTS: Protect returned: CfDJ8ICcgQwZZhlAlTZT...OdfH66i1PnGmpCR5e441xQ

        // unprotect the payload
        string unprotectedPayload = _protector.Unprotect(protectedPayload);
        Console.WriteLine($"Unprotect returned: {unprotectedPayload}");
        //PRINTS: Unprotect returned: Hello world
    }
}

一般来说,这并不是你想要做的事件。我集体只在解决明码重置和相似的令牌时须要它。

有什么是我不应该应用数据保护的吗?

重要的一点是,数据保护零碎并不是真正用于通用加密。咱们心愿你加密的货色,就其本质而言,有一个无限的生命周期,如身份验证令牌和明码重置令牌。

实践上,你能够对心愿加密和长期存储的数据 (例如在数据库中) 应用数据保护零碎。数据保护密钥每 90 天过期一次(默认状况下),然而你依然能够应用过期的密钥解密数据。

如果数据保护密钥因为某种原因被删除,真正的危险就来了。不倡议这样做,但意外总是会产生的。如果应用正确,删除数据保护密钥对大多数应用程序的影响绝对较小——用户将不得不再次登录,以前收回的明码重置键将有效——这很烦人,但不会造成劫难。

另一方面,如果你曾经用数据保护零碎加密了敏感数据,而后将其存储在数据库中,那么就有大问题了。那些数据都不见了,被毁了。相对不值得冒这个险! 相同,你应该应用.NET Core 中的专用加密库,以及为此目标创立的特定证书或密钥。

如何在我的 ASP.NET Core 中配置数据保护?

通常,你与数据保护零碎交互的惟一中央是配置它的时候,如果没有正确地配置它,你可能会裸露于安全漏洞中,或者无奈解密身份验证 cookie。

一方面,数据保护零碎须要易于配置和保护,因为复杂性和保护开销通常会导致 bug 或不良实际。但 ASP.NET Core 还须要在各种环境下运行:Windows、Linux、macOS; 在 Azure, AWS; 在高端服务器和树莓派上。每个平台都有不同的内置加密机制和可用个性,而.NET Core 须要在所有这些平台上都是平安的。

为了解决这个问题,数据保护零碎应用了一种通用的“插件”式架构。基本上有两个不同的可插入区域:

  1. 密钥环持久性地位: 密钥应该存储在哪里?
  2. 持久性加密: 密钥是否应该在静止时加密,如果是,如何加密。

ASP.NET Core 试图在默认状况下将这些设置为正当的选项。例如,在 Windows(非 azure 应用程序)机器上,将长久化到 %LOCALAPPDATA%ASP.net 数据加密密钥。

可怜的是,一旦你开始在生产环境中运行应用程序并对应用程序进行扩大,大多数默认设置都将不起作用。相同,你可能须要钻研一种可选的配置办法。

总结

在这篇文章中,我提供了 ASP.NET Core 数据保护零碎的高级概述。我形容了数据保护零碎的动机以及它背地的一些设计准则。

欢送关注我的公众号,如果你有喜爱的外文技术文章,能够通过公众号留言举荐给我。

退出移动版