ASP.NET加密漏洞是否围绕着一个大谎言工作?

重新:

这与是否将它们重定向到200、404或500有什么关系?没人能回答这个问题,这是最基本的问题。这就是为什么我把需要做这件事的恶作剧称为“愚蠢的习惯错误”,返回200。对于这两个错误,它只需要返回相同的500页。

我认为从最初的问题来看,这并不清楚,我会解决:

谁说错误需要返回200?这是错误的,您只需要所有的错误返回相同的代码,使所有的错误返回500也可以。作为一个解决方案,这个配置恰巧使用了200。

如果你不做变通(即使你自己的版本总是返回500),你会看到404和500的区别。这在webresource.axd和scriptreesource.axd中尤为重要,因为解密的无效数据是一个丢失的资源/404。

仅仅因为您不知道哪个功能有问题,并不意味着ASP.NET中没有在与填充和无效数据相关的不同场景中给出不同响应代码的功能。就我个人而言,我不能确定是否还有其他的特性可以给出不同的响应代码,我只能告诉你这两个特性。

有人能解释为什么为自定义错误返回相同的错误页和相同的状态代码很重要吗?我发现这是无关紧要的,特别是如果这是作为它周围工作的一部分提倡的话。

SRI已经很清楚地回答了你所涉及的问题。

与其说是隐藏错误,不如说是确保攻击者无法分辨错误之间的区别。具体来说,是要确保攻击者无法确定请求是否失败,因为它无法解密/填充无效,而不是因为解密的数据是垃圾。

你可以争辩:但是我可以确保它不会对应用程序造成垃圾。当然,但是你需要在应用程序中找到一个允许你这样做的机制,并且攻击的工作方式,你总是需要在消息中至少有一点垃圾。考虑这些:

• ScriptResource和WebResource都会引发,因此自定义错误会隐藏它。
• 视图状态默认为未加密,因此默认情况下它不涉及攻击向量。如果您遇到打开加密的麻烦,那么很可能会将其设置为对其进行签名/验证。在这种情况下,解密失败与验证失败是相同的,因此攻击者又不知道。
• 身份验证票据也会签名,因此它类似于视图状态场景
• 会话cookie没有加密,因此它与

我张贴了 on my blog 攻击如何能够伪造身份验证cookie。

对于脚本/应用程序来说,执行这种攻击是否同样容易,并且不特别关心它是否获得HTTP状态代码以及更多有关结果的信息?例如,这样做4000次,你会被重定向到一个错误页面,在4001上,你会停留在同一个页面上,因为它不会使填充无效?

如上所述,您需要找到一个这样的机制,即解密垃圾保持在同一页上,而不是抛出异常/从而使您进入同一错误页。

或者失败,它们在一个页面上,并且视图状态不包含它们的数据。无论您在这里做什么,都无法删除失败案例,因为除非成功破解密钥,否则页面将永远不会包含插入的数据。这就是为什么我不能证明自定义错误用法有任何效果的原因。

或者通过,它们在一个页面上,并且视图状态包含它们插入的数据。

阅读我上面提到的视图状态。还请注意,在获得解密能力后,可以更准确地重新加密。也就是说,如上所述,在默认情况下,视图状态不是这样的,当它在其上时通常伴随着签名/验证。

我要详细说明 my answer in the thread 你引用了。

要摆脱攻击,应用程序必须以三种不同的方式响应。这三种不同的方法可以是任何东西——状态代码、不同的HTML内容、不同的响应时间、重定向,或者你能想到的任何创造性的方法。

我再重复一遍-攻击者应该能够在不犯任何错误的情况下识别三个不同的响应,否则攻击将无法工作。

现在我们来讨论一下建议的解决方案。它起作用,因为它将三个结果减少到两个。它是怎么做到的?catch all错误页使状态代码/html/redirect all看起来完全相同。随机延迟使得仅仅根据时间来区分两者是不可能的。

所以,这不是谎言,它确实如广告所示。

正在讨论的攻击允许攻击者将数十亿个请求减少到几千个。这是可能的,因为有3种不同的响应状态。正在提议的解决方案将这一问题还原为暴力攻击,这种攻击不太可能成功。

解决方法之所以有效,是因为:

• 您没有给出任何关于“多远”的指示,轻微调整带您走。如果您收到另一条错误消息,这就是您可以学习的信息。
• 随着时间的推移,你隐藏了实际计算所花的时间。所以你得不到信息,这表明如果你深入系统,你可以从中学习。

不,这不是什么大谎言。见 this answer 在这个问题上你引用了一个很好的解释。