One of my sites has been the target of a spam attack today, with the form filled in with links to a adult site (not clicked on it so not sure if it is).
I’ve changed the form and ticked the spambot option, but the spam is still arriving. They are still using the old form, not the new updated one.
Hi Steve,
Change the name of your form page in Freeway and republish and upload. The PHP file that the spammers are targeting will change names in line with the form page.
Also switch on the spam trap and IP tracking options. If the issue persists block the spammers IP address(s) with an .htaccess file.
Regards,
Tim.
On 31 Mar 2011, at 13:25, SteveB wrote:
One of my sites has been the target of a spam attack today, with the form filled in with links to a adult site (not clicked on it so not sure if it is).
I’ve changed the form and ticked the spambot option, but the spam is still arriving. They are still using the old form, not the new updated one.
By the way, what format does the .htaccess take so that I can block the ip address if need be.
Thanks,
Steve
On 31 Mar 2011, 12:34 pm, Tim Plumb wrote:
Hi Steve,
Change the name of your form page in Freeway and republish and upload. The PHP file that the spammers are targeting will change names in line with the form page.
Also switch on the spam trap and IP tracking options. If the issue persists block the spammers IP address(s) with an .htaccess file.
Regards,
Tim.
On 31 Mar 2011, at 13:25, SteveB wrote:
One of my sites has been the target of a spam attack today, with the form filled in with links to a adult site (not clicked on it so not sure if it is).
I’ve changed the form and ticked the spambot option, but the spam is still arriving. They are still using the old form, not the new updated one.
If you find your spam is coming from an IP range then you could block a whole range if addresses but as the tutorial mentions this could be a bad idea especially where the spammer is using a dynamicly allocated IP address.
Regards,
Tim.
On 31 Mar 2011, at 14:56, SteveB wrote:
By the way, what format does the .htaccess take so that I can block the ip address if need be.
Out of interest, the spam that is still coming through is using the original form, on the revised form I deleted one of the input areas, and when tested this was obvious. But the new spam still has the inputs from the old (original) file.
This is what is confusing me Steve because there are measures within the PHP to stop spammers from posting to the file from outside of your domain. If I try and post to your PHP file I’ll get redirected to the error page. I guess they could be spoofing the referrer header so the request looks like it is legitimate but it is hard to tell without trawling through your sever logs.
Regards,
Tim.
What they have done is to “scrape” your form, save it to their local
system, and then use their copy to send to the -go file. That way they
don’t have to interact with your server at all, just broadcast their
spam to you.
Walter
On Mar 31, 2011, at 10:32 AM, SteveB wrote:
Hi Tim,
Thanks, just what I need.
Out of interest, the spam that is still coming through is using the
original form, on the revised form I deleted one of the input areas,
and when tested this was obvious. But the new spam still has the
inputs from the old (original) file.
As an aside I’ve been considering doing away with the referrer checks in the PHP and replacing them with a session variable that is set on the form page and then read in the -go.php file. The downside is that the form page would have to be php enabled to do this - at which point I may as well post the data back to the same page.
If you can think of a better solution for checking the referrer then I’m all ears/eyes.
Thanks,
Tim.
On 31 Mar 2011, at 16:01, Walter Lee Davis wrote:
This is trivially easy to do, there’s really nothing besides a constantly-changing shared secret to keep this on the level.
Great to get an insite as to how this sort of thing is achieved. It’s like a neverending game where the goalposts keep moving, and we are sometimes the ones who have to move them to stop unscrupulos people taking advantage of our servers.
I’m touching wood frantically as I write this (my desk is real wood), but it seems that the last of the spam emails was at 15.04 BST this afternoon, and none since then. It’s now after 17.00.
I’ll keep a close eye on my Junk folder for any more spam.
You could load the variable into the form page with an Ajax request, I
think.[1] That might get around the problem, and stop a certain
percentage of bots cold in the process (those that don’t execute
JavaScript). You’re never going to get around the “roomful of
underpaid bored people” threat, but then nothing much (even CAPTCHA)
will.
As an aside I’ve been considering doing away with the referrer
checks in the PHP and replacing them with a session variable that is
set on the form page and then read in the -go.php file. The downside
is that the form page would have to be php enabled to do this - at
which point I may as well post the data back to the same page.
If you can think of a better solution for checking the referrer then
I’m all ears/eyes.
Thanks,
Tim.
On 31 Mar 2011, at 16:01, Walter Lee Davis wrote:
This is trivially easy to do, there’s really nothing besides a
constantly-changing shared secret to keep this on the level.
You could load the variable into the form page with an Ajax request, I think.[1] That might get around the problem, and stop a certain percentage of bots cold in the process (those that don’t execute JavaScript). You’re never going to get around the “roomful of underpaid bored people” threat, but then nothing much (even CAPTCHA) will.