1

为什么（除了道德原因）没有更多的人在出售所述验证码的解决方案时使用其他网站的验证码作为自己的验证码？

对我来说，这样的系统似乎很容易实现：

  • 在另一个网站上设置一个脚本，该脚本需要通过使用代理服务完成验证码
  • 当您网站上的用户执行需要完成验证码的任务时，只需向他们提供其他网站要求您解决的验证码
  • 当用户解决 CAPTCHA 时，您的脚本可以在作为 CAPTCHA 来源的其他站点上执行所需的操作，并且您站点上的用户也通过此过程验证

这是家常便饭吗？如果不是，为什么不呢？如果有的话，可以做些什么来防止这种情况发生？

4

1 回答 1

0

获取验证码。假设人们可以轻松地从外国主机获取验证码的确切视觉效果。为此，您必须通过推荐检查（大多数浏览器（由人类导航）允许发送http_referer）。session_id您还必须secret从hidden input. 检查结果。外部主机必须将保存的变量与与您的第一个请求的会话关联的变量链接起来，这需要您实现棘手的cURL方法。您将不得不处理多个并行请求，所有这些请求都来自您的单个 IP。

与自己生成验证码相比，在外国主机上破解验证码时，您的服务器可能会使用更多资源。

防止

  1. http_referer 检查
  2. 将单个 IP 的请求限制为例如 5 个/分钟
  3. 良好的会话处理和棘手的 cookie
  4. 对 javascript 进行逆向工程并非不可能，但是您的 javascript 越复杂，...
  5. 您必须找到一种能够识别外部主机上的结果的模式。最简单的签名可能是Location标题字段，导致/path/success.html或/path/tryagain.php

挑战：

我花了一点时间准备一个例子：http ://woisteinebank.de/test/

在此示例中，我将密钥附加到session_id();并将其保存在数据库中。通过session_regenerate_id();我对每个请求都有一个新的会话。在check.php中，我将数据库值与$_GET值进行比较。

试着想办法得到这个验证码，我会尽力捍卫。每次您在您的网站上成功使用我的验证码时，我都会尝试为它辩护。

于 2013-07-08T19:57:58.490 回答