让验证码暂时对用户具有粘性?

发布于 2024-10-20 19:11:53 字数 352 浏览 1 评论 0原文

我有一个允许匿名发帖的论坛,并受验证码保护。为了方便用户,我为这样的用户设置了一个持续一个月左右的Cookie,这样用户就不会一遍又一遍地获取验证码。最简单的 Cookie 称为 no_captcha_for_one_month,其值为 1。当用户返回并匿名发帖时,他不会得到验证码。

有人看到缺陷了吗?论坛垃圾邮件发送者只需正确填写一次验证码并为其机器人使用 cookie 信息即可。

我想过发挥创意并使用服务器端哈希,其中包括例如用户 IP 地址和一些秘密盐来生成 cookie 值,但当然,它对于该 IP 地址仍然有效。

有人给我的印象是这个问题很愚蠢,我试图解决一些无法解决的问题。

I've a forum where anonymous is allowed to post, protected by CAPTCHA. For users convenience, I set a Cookie for such a user which lasts about a month so the user does not get the CAPTCHA over and over again. In the simplest form the cookie is called no_captcha_for_one_month and it's value is 1. When the user returns and posts anonymously, he gets not CAPTCHA.

Anyone seeing the flaw? A forum spammer just needs to fill out the CAPTCHA correctly once and use the cookie information for his bot and there he goes.

I thought about getting creative and using a server-side hash which includes e.g. users IP address and some secret salt to generate the cookie value, but it would still be valid for this IP address, of course.

Someone I get the impression the question is silly and I try to solve something unsolvable.

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

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

发布评论

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

评论(5

此刻的回忆 2024-10-27 19:11:53

我建议实施您的 cookie 值 + salt 实施不是为了解决您的问题,而是出于安全原因。正如这篇博客文章所解释的,wordpress 已经由于 cookie 安全性差,存在类似的问题,尽管它更严重。在您的情况下,即使 cookie 已过期,顽固的垃圾邮件发送者也始终可以绕过您的验证码。

为了解决所提出的问题,我想到的唯一解决方案是实施强制验证码算法,如果它认为用户正在发送垃圾邮件,该算法将覆盖您新保护的 cookie。我会立即使用一些属性,例如自上次发布以来的时间、今天的帖子数量、在表单上撰写消息所需的时间长度等。

编辑:我还应该提到,您可以让您的论坛更少首先通过在用户提交的链接上实施 rel="nofollow" 属性来吸引垃圾邮件发送者。请参阅维基百科

I would recommend implementing your cookie value + salt implementation not to solve your problem but for security reasons. As explained by this blog post wordpress had a similar, albeit it much more severe, problem due to poor cookie security. In your case a determined spammer could always bypass your CAPTCHA even if the cookie had expired.

In order to solve the proposed problem the only solution that is coming to my mind would be to implement a Forced CAPTCHA algorithm that would override your newly secured cookie if it felt the user was being spammy. Off the top of my head I would use attributes like time since last post, number of posts today, the length of time it took to compose the message on the form, etc.

Edit: I should also mention that you can make your forum less attractive to spammers in the first place by implementing the rel="nofollow" attribute on user submitted links. See Wikipedia.

Spring初心 2024-10-27 19:11:53

通过这样的解决方案,机器人始终可以使用 cookie。无论你尝试什么。

with such a solution it is always possible to use the cookie for a bot. no matter what you try.

£冰雨忧蓝° 2024-10-27 19:11:53

如下所述,可以轻松地从浏览器获取 cookie 并将其粘贴到机器人代码中,因此该解决方案并不可靠。

其他解决方案:

  • 找到一些在论坛上发帖较多的用户,询问他们是否自愿担任版主。像 AutoHotkey 这样的论坛就使用这个系统,而且效果很好。垃圾邮件发送者倾向于避开审核快速且高效的活跃论坛。他们更喜欢死论坛...
  • 限制每个 IP 地址的匿名帖子数量。可能会让用户烦恼,但可以避免垃圾邮件泛滥。仅当您遇到此类洪水时才应设置。

As said below, a cookie can easily be taken from a browser and pasted in a bot code, so the solution isn't robust.

Other solutions:

  • Find some users posting a lot in the forum and ask them if they are volunteer to be moderator. A forum like the AutoHotkey one uses this system, and this works fine. Spammers tend to avoid active forums where moderation is fast and efficient. They prefer dead forums...
  • Limit the number of anonymous posts per IP address. Can be annoying for users, but can avoid spam flooding. Should be set up only if you experience such flooding.
心房敞 2024-10-27 19:11:53

更糟糕的是,因为您使用的是 cookie,垃圾邮件发送者甚至不需要执行一次验证码。 Cookie 可以由客户端更改,它们由浏览器随页面请求发送,因此客户端可以发送任何它想要的内容。事实上,垃圾邮件请求可能来自脚本,因此伪造 cookie 更加容易。

存储变量服务器端解决了我提到的问题;您设置一个随机散列作为 cookie,并在服务器上有一个存储验证码状态的表。为了使垃圾邮件发送者无法获得验证码,他们必须猜测具有存储在服务器端的正确变量的哈希值,这是很难做到的。

您提到的问题;事实上,每月一次可能不足以阻止垃圾邮件发送者,这是您无法回避的。您必须向每个真实用户显示验证码,就像您希望垃圾邮件发送者也输入验证码一样。请记住,验证码是必要的,因为您无法区分垃圾邮件发送者和普通用户。

您应该经常显示验证码,无论如何它都会说服人们注册。

Even worse, because you are using a cookie, the spammer doesn't even need to do the CAPTCHA once. Cookies can be changed by the client, they are sent by the browser with the page request, so the client can send whatever it wants. In fact spam requests would come from a script, so it's even easier to fabricate the cookies.

Storing the variable server side sill solve the problem I've mentioned; You set a random hash as the cookie, and have a table that stores the CAPTCHA status on the server. For the spammer to get no CAPTCHA, they would have to guess a hash that has the correct variable stored server side, shich is very hard to do.

The problem you mentioned; the fact that once a month might not be long enough to deter a spammer, you can't get around that. You have to show a CAPTCHA to every real user, as often as you want the spammer to enter one as well. Remember, a CAPTCHA is necessary because you can't tell a spammer from a normal user.

You should have the CAPTCHA show often, it will convince people to sign up anyway.

太阳哥哥 2024-10-27 19:11:53

加密时间(以皮秒或纳秒为单位)将其设置为输入值 () &将其设置在数据库中,并

在每个页面中设置 列名称“哈希”看看它是否与数据库匹配。

Encrypt the time (in pico or nano seconds) set it as a input value () & set it in your DataBase with a column name 'hash'

set that in every page & see if it matches the DB.

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