2

我们有一个 Web 应用程序，它在 url 中传递参数，如下所示：

www.example.com/ViewCustomer?customer=3945

合理地经常，我们会看到尝试访问：

www.example.com/ViewCustomer

或者系统将此记录为无效并发回“发生错误，请联系支持人员，跟踪号为 XXX”类型页面。

我们的日志包含会话信息，因此它实际上是使用有效会话登录的人，这意味着他们已使用用户名和密码成功登录。

可能是他们只是在地址栏中输入了该内容，但这种情况似乎发生得太频繁了。另一种选择是我们的代码中有一个错误，但我们已经调查过，有时只有一个地方，这显然是可以的。我们从未有过用户抱怨某些东西不起作用并导致这种情况。一切都在 SSL 之下。

有没有其他人经历过这个？某些浏览器是否偶尔会发送这些狡猾的请求？

编辑：我们的日志显示：

 user-agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
4

6 回答 6

2

您的日志是否包含推荐人信息？如果存在任何信息，那么它可能有助于查明错误。如果没有，则可能表示“编辑 URL”尝试。（诚​​然，我不知道 SSL 会改变多少。）

浏览器有时会预取链接，但我不知道他们是否会摆脱该参数——而且他们似乎不太可能为 HTTPS 这样做。

您对这些请求使用哪些浏览器有一个模式吗？

于 2008-10-09T09:05:20.657 回答
1

我已经在我们支持的 Web 应用程序中看到了这一点 - 一个已经登录的用户突然出现的杂散 GET 请求，破坏了服务器端状态并导致后续合法 POST 请求出错。

由于在我们的例子中，URL 使用 URL 重写将 sessionid 附加到 URL，因此 GET 有时也会有旧的 sessionid。

在导致解决此问题的特定日志文件中，这些杂散请求的代理字符串与同一会话中的其他请求不同（尽管有效）。

我相信不是浏览器本身，而是一些插件/扩展。代理可能会执行此操作，甚至是恶意软件。

我们通过禁止对相关 URI 的 GET 请求来克服这个特殊问题。

但是，现在我正在处理一个类似的问题，即 POST 请求突然出现在它不应该出现的地方，唯一的区别在于“接受”标头。

于 2009-02-15T20:01:49.227 回答
1

我现在认为这实际上是一个 tomcat 错误getParameter() 在 POST 上使用 transfer-encoding: chunked 失败。

于 2010-02-22T00:01:50.943 回答
0

检查您的日志中的代理字符串，并查看这些请求是否由搜索引擎蜘蛛发出。

于 2008-10-09T10:32:31.013 回答
0

我知道我有时会删除参数只是为了检查那里有什么。我确定我不是唯一一个。

于 2008-10-09T10:44:14.280 回答
0

一些流氓爬虫将用户代理更改为浏览器的用户代理并爬取页面。这也可能是这样一种情况。

此外，大多数爬虫确实会尝试将其他一些值替换为查询参数以获取未链接的页面。

于 2008-10-21T06:11:40.413 回答