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

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

在此之前来自GET / POST世界,我没有一个很好的基础来理解为什么人们会遇到加密查询字符串的麻烦,当使用POST来处理敏感数据(以及SSL)会达到类似的水平安全。

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


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

您可能会执行此类操作的原因是为了防止篡改URL以访问除您自己之外的数据。 例如,如果您有url:

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

我(或任何人)将其改为:

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

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

这种方法确实可以正确地实现这一目的,但是更加健壮的方法是在应用程序中主动检查授权,并且绝不仅仅依赖URL进行身份validation和/或授权。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 John | Sample | Edit Me! Jane | Sample | Edit Me! 

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

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

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

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


另请注意:默认情况下,viewstate 加密。 它只是通过Base64编码 。 添加一个哈希,以便您可以查看它是否已被篡改。

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

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

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

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

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

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

说到最需要的URL(或查询字符串) – 我个人认为加密它们毫无意义,因为没有理由这样做。