这个问题是对这个新的ASP.NET安全漏洞有多严重以及如何解决它的后续行动？因此，如果我的问题似乎被打断了，请先阅读这个问题及其公认的解决方案，然后将其纳入我的问题范围。

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

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

我明白了为什么将延迟添加到错误页面有点相关，但这是否也只是添加另一个层来愚弄脚本，使其认为站点是无效的目标？

如果脚本考虑到由于站点是ASP.NET，它运行的是AES加密，忽略错误页的时间，并将重定向或缺少重定向作为响应向量，那么可以采取什么措施来防止这种情况发生？如果一个脚本这样做，意味着没有办法阻止它吗？

编辑：我接受定时攻击减少，但错误页面部分看起来确实是假的。这个攻击向量将他们的数据放入视图状态。只有两个箱子。通过。失败了。

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

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

获取webreresoure.axd/scriptreesource.axd中的密码键，并使用验证键的第一个猜测来生成具有加密文本的潜在密钥的值。

此时，如果正确猜测解密密钥，则会将此值传递给webresource.axd/scriptreesource.axd，但由于数据是垃圾数据，因此它将查找webresource.axd/scriptreesource.axd将返回404错误。

如果未成功猜测解密密钥，则填充无效异常时将得到500个错误。此时，攻击应用程序知道增加潜在的解密密钥值，然后再次尝试重复，直到从webresource.axd/scriptreesource.axd中找到第一个成功的404。

在成功推导出解密密钥之后，可以利用该站点查找实际的机器密钥。

重新：

How does this have relevance on whether they're redirected to a 200, 404 or 500? No one can answer this, this is the fundamental question. Which is why I call shenanigans on needing to do this tom foolery with the custom errors returning a 200. It just needs to return the same 500 page for both errors.

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

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

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

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

Can someone explain why returning the same error page and same status code for custom errors matters? I find this to be immaterial especially if this is advocated as part of the work around to it.

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

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

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

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

我在我的博客上发布了攻击是如何变得越来越像能够伪造认证cookie。

Isn't it just as easy for the script/application to execute this attack and not specifically care whether or not it gets a http status code and more on the outcome? Ie doing this 4000 times you get redirected to an error page where on 4001 you stay on the same page because it didn't invalidate the padding?

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

Either Fail, they're on a page and the viewstate does not contain their data. No matter what you do here there is no way to remove the fail case because the page just will never contain their inserted data unless they successfully cracked the key. This is why I can't justify the custom errors usage having ANY EFFECT AT ALL.

Or Pass, they're on a page and the viewstate contains their inserted data.

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

我将在你提到的线索中详细阐述我的答案。

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

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

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

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

编辑：你把事情和暴力攻击混为一谈。服务器总是会有一个通过/失败的响应，您是对的，它不能被阻止。但是，对于攻击者来说，利用这些信息来获取其优势将需要数十年和数十亿次对您的服务器的请求。

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

解决方法之所以有效，是因为：

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

不，这不是什么大谎言。请参阅您参考的问题中的这个答案，以获得一个很好的解释。