这个问题在某种程度上是一个跟进How serious is this new ASP.NET security vulnerability and how can I workaround it?所以，如果我的问题似乎被打破了，首先阅读这个问题及其接受的解决方案，然后将其纳入我的问题的背景中 .
有人可以解释为什么返回相同的错误页面和相同的自定义错误状态代码很重要？我发现这是无关紧要的，特别是如果这是作为其工作的一部分提倡的话 .
是不是脚本/应用程序执行此攻击同样容易，而不是特别关心它是否获得http状态代码以及结果更多？即这样做了4000次，你被重定向到一个错误页面，在4001你留在同一页面，因为它没有使填充无效？
我知道为什么在错误页面中添加延迟有点相关，但是这也不会只是添加另一层来欺骗脚本以为该站点是无效目标？
如果脚本考虑到，由于该站点是asp.net，它运行AES加密，它会忽略错误页面的时间并监视重定向或缺少重定向作为响应向量，可以做些什么来防止这种情况？如果脚本这样做意味着没有办法阻止它？
Edit: 我接受定时攻击减少但错误页面部分真的看起来很虚伪 . 此攻击向量将其数据放入视图状态 . 只有2个案例 . 通过 . 失败 .
要么失败，要么在页面上，并且视图状态不包含其数据 . 无论你在这里做什么，都无法删除失败案例，因为除非成功破解密钥，否则页面将永远不会包含其插入的数据 . 这就是为什么我无法证明自定义错误的使用是否具有任何效果 .
或者通过，它们位于页面上，并且视图状态包含其插入的数据 .
此漏洞摘要
获取来自WebResoure.axd / ScriptResource.axd的密钥，并且使用验证密钥的第一个猜测来生成具有加密文本的潜在密钥的值 .
此时此值传递给WebResource.axd / ScriptResource.axd，如果解密密钥被正确猜测，他们的响应将被接受但由于数据是垃圾，因此它正在寻找WebResource.axd / ScriptResource.axd将返回404错误 .
如果未成功猜到解密密钥，则填充无效异常将收到500错误 . 此时，攻击应用程序知道增加潜在的解密密钥值并再次尝试重复，直到它从WebResource.axd / ScriptResource.axd找到第一个成功的404 .
成功推导出解密密钥后，可以使用该网站来查找实际的机器密钥 .
4 回答
re:
我不认为原来的问题很清楚，我会解决它：
谁说错误需要返回200？这是错的，你只需要所有的错误来返回相同的代码，使得所有错误返回500也会起作用 . 配置提议作为一个解决方案恰好使用200 .
如果您不进行解决方法（即使它自己的版本始终返回500），您将看到404与500之间的差异 . 在webresource.axd和scriptresource.axd中尤其如此，因为解密的无效数据是缺少的资源/ 404 .
仅仅因为您不知道哪个功能存在问题，并不意味着asp.net中没有功能在不同的场景中提供与填充与无效数据相关的不同响应代码 . 就个人而言，我不能确定是否还有其他功能可以提供不同的响应代码，我只能告诉你那些2 .
斯里兰卡已经在你所关联的问题中非常清楚地回答了这个问
它不是隐藏而不是发生错误，而是确保攻击者无法区分错误 . 具体是关于确保攻击者无法确定是否请求失败，因为它无法解密/填充无效，因为解密的数据是垃圾 .
你可能会说：好吧，但我可以确保它对应用程序来说不是垃圾 . 当然，但你需要在应用程序中找到一个允许你这样做的机制，以及攻击的工作方式你总是需要在消息中至少有一点点垃圾 . 考虑这些：
ScriptResource和WebResource都抛出，因此自定义错误会隐藏它 .
默认情况下视图状态未加密，因此默认情况下它不涉及攻击向量 . 如果您遇到打开加密的麻烦，那么您很可能将其设置为签名/验证它 . 当那个's the case, the failure to decrypt vs. the failure to validate is the same, so the attacker again can't知道 .
Auth票也签名，因此它就像查看状态场景一样
会话cookie未加密，因此无关紧要
我发布了on my blog攻击到目前为止如何能够伪造身份验证cookie .
如上所述，您需要找到一种行为方式的机制，即解密的垃圾停留在同一页面上，而不是抛出异常/从而使您进入相同的错误页面 .
阅读我上面提到的关于视图状态的内容 . 另请注意，在获得解密功能后，可以获得更准确地重新加密的能力 . 也就是说，如上所述，默认情况下视图状态不是那种方式，而且当它通常伴随着签名/验证时 .
我将详细说明您引用的my answer in the thread .
要完成攻击，应用程序必须以三种不同的方式响应 . 这三种不同的方式可以是任何东西 - 状态代码，不同的HTML内容，不同的响应时间，重定向或您可以想到的任何创造性方式 .
我将再次重复 - 攻击者应该能够识别三个不同的响应，而不会犯任何错误，否则攻击将无法工作 .
现在来提出解决方案 . 它有效，因为它将三个结果减少到只有两个 . 它是如何做到的？ catch-all错误页面使状态代码/ html / redirect看起来完全相同 . 随机延迟使得不可能仅基于时间来区分一个或另一个 .
所以，它不是谎言，它确实像宣传的那样工作 .
编辑：你正在用蛮力攻击混合起来 . 服务器总会有通过/失败响应，你是对的，无法阻止 . 但是对于攻击者而言，使用该信息对他的优势将需要数十年和数十亿的请求到您的服务器 .
正在讨论的攻击允许攻击者将数十亿请求减少到几千 . 这是可能的，因为3个不同的响应状态 . 正在提议的解决方法将这种方法缩减为蛮力攻击，这种攻击不太可能成功 .
解决方法有效，因为：
你没有给出任何有关"how far"的指示 - 略微调整了你 . 如果您收到另一条错误消息，那么您可以从中学习这些信息 .
延迟时间隐藏实际计算所花费的时间 . 因此，您无法获得信息，这表明您是否深入了解系统，您可以从中学习 .
不，这不是一个大谎言 . 有关详细解释，请参阅您引用的问题中的this answer .