[dokuwiki] Re: Plugin captcha -

  • From: Andreas Gohr <andi@xxxxxxxxxxxxxx>
  • To: DokuWiki Mailinglist <dokuwiki@xxxxxxxxxxxxx>
  • Date: Fri, 3 Feb 2017 14:48:09 +0100

This is fascinating... I looked for captcha solving plugins for chrome
and holy shit are there many. However there are two types of services.
Manual solvers which automate captcha solving by letting third world
users do it and automated solutions using OCR.

Both seem not to match the logs you have.

The leading manual solution seems to be anti-captcha.com which say
their average resolving time is 8.2 seconds. But there's only one
second between the img.php request and the following post. Too fast
for an API roundtrip with a human at the other end of the world
involved.

For automated solutions there's solvecaptchas.com who list their
success rates and for our captcha it should be at 80% maximum. That
means there should be logs of posts that do not result in spam.

If both solutions are not possible it would point to some kind of flaw
in the captcha that is exploited by your spammer.


1. Your spammer always requests the image. Does he always request it
with the same secret? Or is it a new one each time?

It is new always. I couldn't find duplicate secrets in the log from the
spammer. But I think it is possible to use the same secret multiple times.

If that's possible, why request the image again? Why with a new code?

This is a misunderstanding. Accidentally I deleted the spam post from the
last log entries I sent. My fault. At the moment there are 2 small spam
posts visible at my page. If needed I can send the corresponding log
entries. The spam comes in in waves. Yesterday the attacks slows down a bit.
Some numbers from today until round about 9:30am:

528 "GET img.php" from 46.161.9.2
581 "GET img.php" from 46.*
672 "GET img.php" overall (includes me)

now what would be interesting is the number of requests to img.php,
the number of GET requests to the pages being spammed, the number of
POST requests to the same pages and finally the number of spam posts
on all those pages. (all of them filtered for the attacker IPs of
course).

That would give us some statistics about the failure rates.

However that would require to leave open the wiki for spam for some time.


I'll try to not point out senseless suggestions :). But I still think the
issue is about the call of img.php. The spammer uses it by a way beside the
usage through a browser. The cookie is a good idea, but not enough at the
moment. Something else have to be checked before img.php runs.

I could add a check for the cookie in the img.php and only display an
image if the cookie was created beforehand. But since your spammer
always requests the page, then the img and then posts, this wouldn't
change a thing.

To me it looks like the spammer is solving the captcha somehow and
very quick. If you're not willing to experiment with the log numbers
as described above, there are some other experiments I would like you
to run:

* put different ttf fonts in lib/plugins/captcha/fonts
* change the number of letters in the captcha (make it one letter more)
* change the size of the captcha image (I guess make it a bit larger
and change the aspect ratio a bit)
* switch to the new SVG based captcha

I assume the last one will stop your spam completely for the time
being. But it would be incredible helpful if you could do the other
options first and report your findings. Do them one by one and each on
their own, to see which of them make a difference.

I wondering if I'm the only one with this issue.

I guess only very few people are using the blogtng plugin. Maybe the
flaw is in the implementation there?

Andi
-- 
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist

Other related posts:

  1. Home
  2. dokuwiki
  3. Archive
  4. 02-2017