【问题标题】:Exception: 'Invalid webresource request'例外:“无效的网络资源请求”
【发布时间】:2018-05-15 13:09:58
【问题描述】:

我们的 ASP .NET Webforms 应用程序有一个奇怪的异常。
有时会在不同的 .aspx 页面中抛出相同的异常:

错误:这是一个无效的网络资源请求。 网址:https://example.com/WebResource.axd?d=pPvrniqvKCVu4785dN_ahQGLCPzNyr7f4i8DaZgJq2QNfEAadKjdL1N4XhlkzuMFZMX2X0-RCOI_z1vzc5RFMGIe7CAXw7lJqHZw5nlyodAkssADb-0obxsyzubFHcCM-5Kt0Zfm8W7ao0HE6xyQsaV264sX_gMQYPnzPGzAMMk1&t=636618914162471727

来源是 System.Web

这是一个无效的网络资源请求。 在 System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext 上下文) 在 System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() 在 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep 步骤) 在 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

它在我们将服务器从 Windows Server 2012 R2 升级到 Windows Server 2016 后开始.

我试过了:

  1. 将 .Net Framework 升级到最新的 4.7.2
  2. 按照here 的说明应用安全补丁
  3. 确保它不是here 所述的爬行机器人(例外情况是 即使通过我们的 IP 浏览页面,有时也会被抛出)
  4. This 回答,#1 已完成,#2 无关紧要,因为它也来自我们的 IP,#3 我们不经营任何农场。

问题是我们在localhost 上没有看到这些异常,并且不知道如何在服务器上调试它的原因。
任何想法将不胜感激。

【问题讨论】:

  • 逐步从 Global.asax Application_Start 开始。 (?) 检查服务器日志以获取更多详细信息,甚至查看本地机器日志(事件查看器)。
  • 不幸的是,没有本地事件可以指出这个问题。我会通过 Global.asax 看看能不能找到一些东西。谢谢。

标签: c# asp.net webforms


【解决方案1】:

这是评论而不是答案。但我刚刚注册,没有足够的声誉发表评论。道歉。

这些对 WebResource.axd 的无效请求之所以发生,是因为 URL 中的所有加密垃圾都没有解密为服务器上任何有意义的东西。发生这种情况的原因有几个:

  1. 客户端/浏览器缓存了一个旧链接,该链接来自最近的服务器补丁更改了服务器端的加密/解密工作方式 - 例如您的链接引用的 MS10-070 补丁。我不希望这些无效请求在您的日志中非常多,它们最终应该会消失。我不知道最近有任何类似这样影响 ASP.Net 的补丁,所以这可能不是你的问题。
  2. 恶意代理正在扫描以查看您的站点是否容易受到攻击。再次,MS10-070 修补的漏洞就是我脑海中浮现的例子。如果是这种情况,您可能会看到多次尝试使用稍微不同的查询字符串访问 WebResource.axd,同时它会探测所需的信息。仅仅因为您已经修补了服务器,这并不一定意味着您不会看到恶意代理检查您的网站。
  3. 这可能是您的客户端的错误。几年前,IE8 有一个错误会破坏这些 WebResource 字符串的加密部分。您的服务器日志是否跟踪客户端的用户代理字符串?这些错误请求是否来自同一个客户端?相同系列/版本的浏览器?

此查询字符串可能会以多种方式被破坏,并且大多数发生在它以有效响应离开服务器和在后续请求中返回之间的时间。这里有一些我会回答的问题,以帮助缩小问题的范围。导致错误的 url 实际上是无效的吗?还是那个完全相同的网址在大多数情况下都会导致成功?您知道正在提供的页面包含指向此特定 WebResource.axd 的链接吗?如果您手动请求它,预期的查询字符串是什么样的?它与坏字符串有多相似?

【讨论】:

  • 关于 #1 的更多评论 - 更改加密/解密行为不一定是安全补丁的结果。在过去的几年里,我从 ASP.Net 本身所知道的任何事情都不会迫使你做出这样的改变。但是任何可以为您的应用程序更改 machine.config/web.config 的人都可以更改 machineKey 和随附的验证参数。如果您怀疑 #1 可能是这种情况,请仔细检查以确保您的配置堆栈中的此区域没有任何变化。
  • 感谢您的澄清。 - 导致此错误的 URL 不是无效的。 - 它不是同一个 URL - 它是同一个 WebResource.and URL(包括查询字符串本身) - 不同的 Web 客户端,甚至不同的 IP - 我不手动请求它;其实我不确定代码的哪一部分要求它,可能是一些aspx控件你有线索吗?
  • WebResource.axd 是 ASP.Net 的全方位处理程序,它为 2.0 时代以来的不同 ASP.Net 功能提供支持资源 - 主要是 javascript。诸如 TreeView 之类的东西。只要在页面上使用某些功能,该链接就会包含在页面响应中,然后浏览器可以获取 javascript 并加载它。 ASP.Net 在响应中生成的链接对于生成它的服务器来说始终是正确的——只要服务器在页面响应和随后的资源请求之间不更改其配置。
  • 这意味着在生成原始页面响应之后和 WebResource.axd 请求到达 ASP.Net 之前,查询字符串文本在某处变得混乱。这可能发生在行为不端的代理中。它可能发生在旧的错误版本的 IE8 中。它可能发生在我们不知道的其他错误客户端中。可能是恶意用户试图将 WebResource.axd 作为填充预言机进行探测。或者可能只是有人在服务器配置更改之前很久以前缓存了指向 WebResrouce.axd 的旧链接。
  • 将错误的查询字符串与显示在 IIS 日志中的已知良好查询字符串进行比较可以提供有关问题所在的线索。 IE 随机删除了一大块字符串。它看起来都很好并且与其他好的字符串相似,直到它没有。如果代理正在搞砸事情,则字符串中可能会有类似的缺失部分。与好的请求相比,丢失的长度可能存在一种可识别的模式。也许成功的请求围绕着糟糕的请求可以让您了解哪些功能或类别的客户端遇到了问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-10-06
  • 2020-09-24
  • 2012-11-29
  • 2014-11-20
  • 2019-08-17
相关资源
最近更新 更多