-------- Original Message --------
Subject: Re: [dokuwiki] Re: Plugin captcha -
Date: 2017-02-03 15:56
From: dokuwiki@xxxxxxxxxxxxx
To: dokuwiki@xxxxxxxxxxxxx
... btw, the IP range 46.161.9/24 is a well known for spam.
If both solutions are not possible it would point to some kind of flaw
in the captcha that is exploited by your spammer.
A question I have on my own. Meanwhile I think he is not calling img.php but (maybe) helper.php. But no glue how. If the captcha will be resolved regularly. a "GET ... fetch.php" is the call before "GET ... img.php".
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?
The first 2 numbers are always inside similar to the 4 log entries as I posted - but it is possible that I have overseen something.
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).
If the blog is open then there are no failures.
That would give us some statistics about the failure rates.
Not really sure if this solves the issue, but I would give it a try.
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.
Done! Removed the default fonts. But - I got an unexpected behaviour! I entered a comment and the captcha code. As stated before - decrypt() is disabled in img.php - the captcha failed as expected, but the image shows the same letters again and again. No idea why, will investigate.
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)Did this already. Didn't have any effect.
* change the size of the captcha image (I guess make it a bit largerDid this already as I changed the number of letters.
and change the aspect ratio a bit)That's new to me. I will check it out.
* switch to the new SVG based captcha
Maybe. I did think about that the "comment" button of the blogtng plugin should set something which will be checked in img.php.
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
