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

Question

我在使用C＃/ ASP.NET编写的Web应用程序上工作。此应用程序的原始成帧器选择使用加密的查询字符串和Viewstate来控制应用程序的“安全性”和“状态”。

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

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

---

修改：在这个问题中，人们倾向于关注Viewstate。的不要即可。提到Viewstate只是为了让您更好地确定“状态”是如何管理的，因为它与URL相切。我从未说过Viewstate已加密。确实存在两个问题：1）Viewstate的使用，以及2）加密查询字符串的使用。这个问题集中在后者上。我希望这有助于澄清问题的重点。

Answer 1

您可能会这样做的原因是为了防止篡改URL以访问您自己以外的数据。例如，如果您有网址：

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

我（或任何人）将其改为：

并不难

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

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

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

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

Answer 2

好吧，可以说它允许你为页面分发一个url，但是这里更好的方法可能是将guid作为永久链接的不透明标识符...也许它对脚本目的很有用？

如果它位于同一个应用程序的页面之间，那么通过SSL的POST似乎确实更有意义。你能问原设计师吗？阅读设计文件？

Answer 3

它们可能在诸如用户激活之类的事情中非常有用，您可以直接从浏览器传入明文帐户凭据（尽管可以使用查找令牌轻松解决此问题）。在SSL不可用于POST请求的情况下这很有用，这是我唯一能想到的事实。它通常可以作为客户的强制要求来应用，以阻止意外的数据泄漏，但我想这取决于你的应用程序的偏执。

Answer 4

查询字符串加密的原因是因为它提供了虚假的安全性。它允许商业人士认为它提供了安全性，当它真正提供的是无法保障的障碍时。

在我之前的工作中，我们被迫使用它们，并且我明确表示它绝对没有意义，特别是当我们有一个静态键和静态初始化向量但仍然有人认为它提供了一些东西。

使用加密查询字符串非常糟糕的原因是人们无法实现真正​​的安全性。在其他用户指出您有www.mysite.com/page?userid=25的情况下，他们可以轻松地将25改为100或1等。

在我看来，这是一件好事，用户应该能够做到这一点。这取决于网站，以确保他们不会更改ID并获取未经授权的材料。当出现你受到保护时，很容易就不会强迫真正的安全。

Answer 5

除了给出的所有答案外，您可能还想隐藏服务器日志中的URL数据。

Answer 6

IMO你对这种做法感到困惑是正确的，因为这不是一个好主意。您可以使用多少数据（取决于浏览器）并且应该放入QueryString。

Answer 7

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

Answer 8

关于加密请求字符串，我确实可以想到加密它的一些原因。可能的经典案例是你创建了一个充满了唯一索引人员记录的网格。在每一行中，您可能希望拥有一个指向允许您编辑记录的页面的链接。您可以简单地为每个链接指定一个参数，例如“ID = X”，以便加载相应的记录。

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

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

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

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

关于您的情况，上面显示了一个有用的具体情况。这是否适用于您的情况由您决定。但应该，考虑他们实现的加密是否只替换另一个可猜测的值。

---

另一个注意事项：默认情况下，viewstate 不加密。它只是encoded via Base64。添加一个哈希，以便您可以查看它是否已被篡改。

就您的网络应用程序的安全性而言，确保您接收的数据来自您的用户以及数据在传输过程中未受到损害的唯一可靠方法是通过SSL。

Answer 9

我可以看到加密查询字符串是有用的...让我们说你想阻止用户改变吗？recordID = 1到？recordID = 2

我知道这应该在页面加载上得到保护，但我们都知道不是每个人都这样做

Answer 10

听起来像是一种廉价而开朗的方式来阻止用户摆弄GET参数。我知道我摆弄GET参数以获得我想要的东西。

但是，看起来奇怪的是，从Javascript发送的GET请求也必须对URL进行编码。这将使得以AJAX-y方式使网站交互变得困难。那时，系统到位似乎是有害的。

如果我投票，我会投票给;

1. 重写URL解析机制，使它们接受加密和非加密字符串，
2. 将网址加密功能标记为[Obsolete]
3. 逐步删除加密系统。

Answer 11

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

说到最需要的URL（或查询字符串） - 我个人认为没有必要对它们进行加密，因为这样做并没有理智的借口。