C# 为什么在ASP.NET中加密查询字符串？

我在一个用C#/ASP.NET编写的web应用程序上工作。此应用程序的原始框架选择使用加密查询字符串和

Viewstate

来控制应用程序的“安全性”和“状态”

在此之前，我来自一个GET/POST世界，我没有一个很好的基础来理解为什么人们会遇到加密查询字符串的麻烦，而对敏感数据使用POST（以及SSL）可以达到类似的安全级别

我的问题是：在ASP.NET中使用加密查询字符串的优点和缺点是什么？是否有记录在案的“最佳实践”

---

---

编辑：在这个问题上，人们倾向于关注

Viewstate

不要。提到Viewstate只是为了让您更好地了解“state”是如何管理的，因为它与URL有着千丝万缕的联系。我从来没有说过

Viewstate

是加密的。实际上有两个问题：1）使用

Viewstate

，2）使用加密查询字符串。这个问题的重点是后者。我希望这有助于澄清问题的焦点。

就ViewState而言，ASP.NET运行时已经以几乎所有可能的方式对其进行了加密和验证

---

说到requrest URL（或查询字符串）——我个人认为加密它们没有意义，因为这样做没有合理的借口

可以说，它允许您为页面分发url，但更好的方法可能是使用guid作为永久链接的不透明标识符。。。也许它对脚本编写有用

---

如果是在同一个应用程序的页面之间，那么通过SSL发布的帖子似乎更有意义。你能问问原创设计师吗？阅读设计文档？

在我看来，你对这种做法感到困惑是对的，因为这不是一个好主意。查询字符串中可以放入和应该放入的数据量是有限制的（取决于浏览器）

如果加密是在应用程序的较低级别上完成的，或者如果它是一个框架。它可以是确保内容得到保护，而不管实现如何。即使开发人员决定不使用SSL POST，它仍然受到保护。

关于加密请求字符串，我确实可以想出许多理由对其进行加密。可能典型的情况是，您创建了一个填充有唯一索引的个人记录的网格。在每一行中，您可能都希望有一个指向允许您编辑记录的页面的链接。您可以简单地给每个链接一个参数，例如“ID=X”，以便加载适当的记录

John |  Sample  | <a href="EditPage.aspx?ID=1">Edit Me!</a>
Jane |  Sample  | <a href="EditPage.aspx?ID=2">Edit Me!</a>

John | Sample |
简|样本|

现在，如果所有员工都有权访问所有人员，并且通过身份验证过程对您的页面进行了访问，并且您正在使用SSL（SSL经过协商，所有通信在发送URL参数之前都进行了加密），那么这就不是问题了。但是，考虑一下您有哪些用户可以看到哪些记录的限制的情况。所以，芝加哥的工作人员只能看到分配到芝加哥的人员，纽约的工作人员只能看到纽约的工作人员，等等

现在您遇到了一个问题：有人可能会通过简单地用不同的用户ID重新键入URL来破坏您的位置限制。解决这个问题的一种方法是加密请求参数。不过，也有一些曲折。首先，简单的加密不起作用，因为用户可以尝试另一个加密值。您需要密钥对或一种导致ID和URL参数之间极其稀疏映射的算法。密钥对解决方案（我已经使用并推荐）很简单：只需传递两个加密的复杂值，这两个值一起工作就可以得到一个有效值

请注意，您无法通过会话存储解决此问题，因为您不知道用户将提前选择什么值。同样，Post在处理如此简单的接口设备时也会非常笨拙

就您的情况而言，上面所示的是一个非常有用的具体情况。这是否适用于您的情况由您决定。但是，你应该考虑他们所执行的加密是否仅仅替换了另一个可猜测的值。

---

另一个注意事项：默认情况下，viewstate不加密。这很简单。添加了一个散列，以便您可以查看它是否被篡改

---

就web应用程序的安全性而言，确保您接收的数据来自您的用户，并且数据在传输过程中未被破坏的唯一可靠方法是通过SSL。它们可能在用户激活时非常有用，您可以直接从浏览器中传递明文帐户凭据（尽管这可以通过查找标记轻松解决）。当SSL不可用于POST请求时，它很有用，老实说，这是我能想到的唯一一次。它通常可以作为客户端的强制要求来应用，以阻止意外数据泄漏，但我想这取决于你的应用程序的偏执。

你可能会这样做的原因之一是为了防止篡改用于访问除您自己的数据之外的其他数据的URL。例如，如果您拥有该URL：

http://foo.com/user.aspx?user_id=123

对我（或任何人）来说，将其改为：

http://foo.com/user.aspx?user_id=124

如果您的数据访问策略完全依赖于查询字符串中的内容，则可能会允许未经授权的数据访问

这种方法确实可以正确地达到这一目的，但更可靠的方法是在应用程序中主动检查授权，而不是完全依赖URL进行身份验证和/或授权

请注意，这与SSL无关，SSL可确保浏览器和服务器之间的隐私，但您可以在完全安全的连接下，仍然篡改wi