如何防止密码和其他敏感信息出现在 ASP.NET 转储中？答案

【问题标题】：Hows does one prevent passwords and other sensitive information from appearing in an ASP.NET dump?如何防止密码和其他敏感信息出现在 ASP.NET 转储中？
【发布时间】：2012-04-15 09:30:41
【问题描述】：

如何防止在 IIS/ASP.NET 转储文件中向 ASP.NET 网页提交和接收的密码和其他敏感数据？

复制步骤

使用 Visual Studio 2010，创建一个 ASP.NET MVC 3 Intranet 应用程序。
将其配置为使用 IIS 7.5。
启动它并注册一个帐户（例如 bob123 作为用户，Pa$$w0Rd 作为密码。我假设 SQL Express 数据库已创建并且该站点功能齐全。
使用任务管理器，右键单击 w3wp 进程并创建转储。
在能够将其内容显示为十六进制的编辑器中打开转储，例如 SlickEdit。
在十六进制转储中搜索“Pa$$0Rd”和“Pa%24%24w0Rd”。您应该能够找到以 ASCII、Unicode 或编码形式存储的多个副本。

请注意，是否使用 HTTPS 并不重要，因为它只会加密通信。 ASP.NET 将这些数据以明文形式存储在内存或磁盘中。

问题

常识是加密敏感数据而不是明文存储。但是，员工可能会收到 IIS/ASP.NET 应用程序的转储并发现用户的密码和其他机密数据，因为这些信息既没有加密，也没有在使用后清除 ASP.NET 使用的内存。

这让他们处于危险之中，仅仅是因为他们可以访问它。 Dump 有时会与合作伙伴（如 Microsoft）共享，以帮助他们诊断代码中的问题。它是诊断应用程序中一些非常复杂的问题的必要部分。

我看过的东西

对密码和其他敏感数据使用 SecureString。但是，ASP.NET 成员资格提供程序以及 WCF 等其他框架通常将密码作为 System.String 接受，这意味着这些副本仍将在转储中。
查看框架中是否有任何内容可以在 System.String 不再使用时清除它的副本。我找不到任何东西。
调查是否可以在 IIS 完成后将用于请求和响应的内存归零，但我找不到任何东西。
我调查了是否可以加密 IIS 接收的文件（如 HttpPostFile），这样它们就不会被明文存储。我们可能会收到极其机密的文件，并且每一步都会在服务器上对其进行加密和保护。但是，有人可以从 IIS 转储中直接提取它们。

我希望告诉 IIS/ASP.NET 一个特定的请求/响应包含敏感数据，并且 IIS/ASP.NET 将在使用完成后清除内存。

【问题讨论】：

+1 非常有趣的问题。直到现在我才意识到这一点。我想问您的一个问题是，您是在使用会员资格时对密码进行哈希处理还是以明文形式存储密码？
用两种盐散列。但这并不重要，因为密码在对 ASP.NET 的请求中以明文形式显示，因此在转储中可见。此外，会员提供者收到的副本是清晰可见的。然后还有您的哈希密码的副本。
如果您不是管理员，则无法在步骤 4 中获取转储。如果您没有转储，那么如何执行以下步骤？如果您无法执行以下步骤，那么您的担忧来自哪里？
从公司的角度来看，我认为这更像是您指出的一个问题。在服务器上具有管理权限的人不应突然能够访问业务线系统中的机密数据。例如，使用 OP 问题中概述的方法，IT 管理员可以访问公司工资系统或其他机密系统。
更有可能的攻击是，有人会打电话给您的客户，假装是您的支持部门的员工，并询问他们的密码是什么。如果您对此感到担心，那么我会研究一种不同的身份验证方法，例如硬件令牌 (en.wikipedia.org/wiki/Hardware_token)，它会产生时间敏感的密码。无论如何，正如 Lex 所说，如果有人可以获得转储，他们可能会在您的服务器上安装恶意代码。换句话说，你已经输了。

标签： asp.net security iis-7.5 crash-dumps

【解决方案1】：

根据定义，转储文件会转储所有应用程序在转储时使用的内存，如果您要创建过滤器以排除某些内容，那么您永远无法确定您有足够的数据来解决问题。

您愿意将您的数据库/配置设置交给第三方吗？如果不是，那么您可能也不应该交出转储文件。（恕我直言）

【讨论】：

但是，转储可以准确指示应用程序崩溃的位置，而无需数据库或配置。诊断和解决此类问题具有巨大的价值。没有它，他们可能永远无法解决问题。只是很遗憾，最近已经处理过的 ASP.NET 请求，包括身份验证请求，都在转储中可见。
根据我的经验（8 年的 asp.net 开发），我实际上从未像现在这样“转储”。我总是通过一些记录器（log4net/nlog）自定义记录所有未处理的异常，或者使用 Elmah 之类的东西来发现错误的来源。转储文件应该是你最后的手段，而不是你的第一个......
安德烈亚斯，你是绝对正确的。但是，根据我的经验，我们再次将本机代码与托管代码混合在一起，当应用程序死锁或意外终止时，我们通常只需要转储。后者在纯托管环境中很少见。日志记录仅此而已。
很公平，到目前为止，我已经避免了“去本地化”的麻烦，所以我没有需要。

【解决方案2】：

我知道这并不能直接回答问题，但为什么不换个角度看待这个问题。

您可以轻松地将一些 javascript 放在一起做散列客户端。我会将密码与随机的东西结合起来，例如由服务器发送的 guid，并且仅对单次使用有效。数据交换将不再包含密码，并且哈希值可以很容易地在服务器端进行比较。它只对会话有效，因此查看转储数据的人将来无法使用哈希来“验证”自己。

在文件方面，这些文件是如何上传的？直接从网页？有很多 javascript 库可以进行加密（河豚），我在发送敏感文件时肯定会使用此选项。它确实会降低速度，但您可以确保数据是安全的。

【讨论】：

这当然值得考虑。但是，我也有几个基于 REST 的 Web 服务，服务接受和发送的机密信息可能包含在转储中。
您可以做同样的事情并使用 javascript 加密库加密该数据。但是，这远非理想，因为它在客户端和服务器上都增加了很多开销。 IIS 将 SSL 数据以纯文本形式保存在进程中，这对我来说很疯狂。
不幸的是，我的网络服务被各种客户使用，所以这将变得不切实际。