Cookie 损坏

发布于 2024-12-06 11:16:58 字数 967 浏览 6 评论 0原文

我对执行以下操作的 php 重定向脚本有一个奇怪的问题:

  1. 在用户的浏览器中植入 cookie,或者读取现有的 cookie(如果有)。
  2. 将用户重定向到另一个网址(重定向的网址是原始网址中的一个参数,例如http://my.redir.com?url=www.google.com)。
  3. 记录重定向(时间、用户代理、引荐来源网址、cookie)。

每隔一段时间(非常罕见,百万分之一),我会看到日志文件中的 cookie 已损坏。 当 X 为 af 或 0-9 时,所有 cookie 的格式均为 XXXX-XXXX(因此有效的 cookie 可以是 7bfab3-d8694)。损坏的 Cookie 使用字符 :/ 替换其中一个字符或连字符,例如 7bfa:3-d86947bfab3/ d8694

问题是,什么会导致这种情况? 这可能是我的脚本或其运行的服务器的问题,还是更可能是用户浏览器的问题?

-- 更多信息 --

我发现的损坏的 cookie 具有用户代理:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Sky Broadband; GTB7.1; Sky Broadband; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; Sky Broadband)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4

I have a weird issue with a php redirect script that does the following:

  1. Plant a cookie in the user's browser, or read the existing cookie if there is one.
  2. Redirect the user to another url (the URL for redirect is a parameter in the original URL, e.g. http://my.redir.com?url=www.google.com).
  3. Log the redirect (time, user-agent, referrer, cookie).

Every once in a while (very rare, one in millions), I see a cookie that got corrupted in the log file.
All cookies have the format XXXX-XXXX, when the Xs are a-f or 0-9 (so a valid cookie can be 7bfab3-d8694). The corrupted cookies have the characters : or / replacing one of the characters or hyphens, e.g. 7bfa:3-d8694 or 7bfab3/d8694.

The question is, what can cause this?
Can it be a problem with my script or the server it is running on, or is it more likely to be a problem in the user's browser?

-- more info --

The corrupted cookies I have found had the user-agents:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Sky Broadband; GTB7.1; Sky Broadband; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; Sky Broadband)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

别念他 2024-12-13 11:16:58

各种“废话”机器人写得不好,漏洞百出。我在日志中看到类似的行为,例如,糟糕的(不正确的)HTML 解析器错误地跟踪链接,以错误的方式“清理”或 URL 编码和 URL 解码内容等。

所有这些“代理”字符串看起来就像常规浏览器。有一次我被这个吓坏了,直到我注意到几秒钟之内就有数百个不同的页面被点击。这不可能是一个正在冲浪的人。

因此,我建议您尝试在日志中查看此 IP/代理组合还访问了哪些内容,如果这是一个机器人,请不要担心。

All kinds of "scrapping" robots are badly written, full of bugs. I see similar behavior in my logs, e.g. poor (incorrect) HTML parsers following links incorrectly, "sanitizing" or URL-encoding and URL-decoding stuff in a wrong way, etc.

All this while the "agent" string looks like regular browser. I was freaked by this once, until I noticed how several hundred different pages were hit in a matter of seconds. No chance this is a human being just surfing.

So I suggest you try to see in your logs what else this IP/agent combination was visiting, and if this is a robot, stop worrying about it.

过期以后 2024-12-13 11:16:58

我想说这是客户端故障。但很难判断所有的流量,如果您使用 setcookie() ,请尝试使用 $_SESSION['sess'] = "cookie" 代替,看看问题是否仍然出现。
我希望这有帮助,
问候。

i'd say it's a client side malfunction. but it's hard to tell with all that traffic, if your using for example, setcookie() try using $_SESSION['sess'] = "cookie" instead and see if the problem still occurs.
i hope this helps,
regards.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文