Filter HTTP_REFERER

[polarbear]

I know that formmail.php contains this comment and this is technically correct:

// Note that HTTP_REFERER is easily spoofed, so there's no point in
// using it for security. 

But a lot of spammers don't bother spoofing it, so one can filter out some spam at least and filtering a HTTP_REFERER from a different domain is better than nothing.

So I suggest to include HTTP_REFERER filtering it in the future.

PB

[russellr]

Hi,

Yes, I know you're right about some spammers not bothering to spoof referrer.

The problem is that referrer checks also break things.

We've come across some servers that don't pass the referrer through to PHP.

Also, some people's browsers don't pass it through and some PC's have "security" software installed to block this information.

Overall, we think it's much more trouble than it's worth.

We're more interested in automated ways of preventing spam attacks, such as those already built into FormMail.

From the feedback we've got, people can get virtually zero spam without using Captcha by using the other anti-spam features in FormMail.

If someone is getting successfully attacked by a bot while using these features, then we really want to see the details so we can analyze the problem and solve it.

[polarbear]

)Yes I agree, since swapping over from nms Formmail to your Aussie product a fortnight ago, I reduced heaps of URL spam.

But on a daily basis I have people calling the formmail.php script directly therefore bypassing any configuration (like required fields etc). The common thing they have is a long and foreign referrer with a few hundred characters of URL parameters (like 2FelZjiKwBU%2Bq1%2FYd9XDNwrkiPeb%2Bw6kbHVHWFGNGuuYu9UcBFbUOGwNiZaajBpCslpvszBPjp2YWRByLTMOB4fHfTKcQMjnWRZjFLLY%2Bw0%2BQ6OLIDuhdcM%2Frw5kLpeA0Ld4xsE%2F031e%2FtYpMCk2b0zAznWGB3o8%2FSESozMbBK2sA2FxCA1HIKYju33qolgRPzOcZogI6KcRF.

PB

[russellr]

Hi,

Does this come through in the email as junk words?

If so, check out this feature:
http://www.tectite.com/fmdoc/attack_detection_junk.php

[polarbear]

Unfortunately the junk is not in the normal fields, only in the referrer field.

I have two cases:

a) Two fields submitted: email and realname both empty, a long "junky" URL in the referrer. I think the only way to achieve this is calling formmail.php directly rather than through a form. No idea how they manage to have the email field empty. No idea what purpose it has to send junk in the referrer field.

b) A dummy email and one field filled in and a long URL with junk parameters in the referrer.

Since the junk is in the referrer rather in a field the junk filter you are referring to won't work for this case.

PB

PS: The first case a) concerns me most.

[russellr]

Hi,

My suggestions....

Use an INI file to make "email" a required field.

You could also derive a field from the referrer information and then configure junk detection and FormMail may reject the spam based on that (derived) field.

Here are the relevant HOW TO guides and documentation:
http://www.tectite.com/fmhowto/inifile.php
http://www.tectite.com/fmhowto/derived.php
http://www.tectite.com/fmdoc/attack_detection_junk.php

[polarbear]

Thank you for your suggestions.

Use an INI file to make "email" a required field.

Good idea, will be done ASAP.

You could also derive a field from the referrer information and then configure junk detection and FormMail may reject the spam based on that (derived) field.

Won't work as deriving field cannot be configured in ini files and they post directly to formmail.php.

PB

[polarbear]

Russell,

I did run into a snag with having the required parameter in the ini file: The ini file required parameter overrides the form hidden field parameters.

For most forms I have different required parameters.

So the ini file parameter should be a default but one should be able to add to those using hidden fields.

PB

[russellr]

Hi,

Won't work as deriving field cannot be configured in ini files and they post directly to formmail.php.

Ooops...that's right.

I did run into a snag with having the required parameter in the ini file: The ini file required parameter overrides the form hidden field parameters.

For most forms I have different required parameters.

So the ini file parameter should be a default but one should be able to add to those using hidden fields.

Yes, that's a snag too.

We'll be doing something better with INI files soon.

Anyway, your FormMail is being hit with a GET request. You can adjust your .htaccess (assuming you're using Apache) to disallow any GET requests to your FormMail script.

Your forms are using POST (probably), so that will stop this particular attack straight away.

[russellr]

Hi,

I should say "if your FormMail is being hit with a GET request"....