password protection [sic] bypassed;-(

whooami—-
Have set up a webshare on my server (usern/passw in email).
PDF (PC/MAC) of my working log sitting in the webshare.
“” noted and amended on live .htaccess files.
My sites should not be down (hardly ever)… you may be on the RBL. At the moment my RBL-adding reflexes are some trigger-happy, there’s a lot of world out there blocked! Privately let me know your working IP so I can keep it live. Look forward to the troubleshooting link, have a good sleep;~)
—-best wishes, Robert

In the context of this thread (contact forms) is this of any interest? -> https://www.alt-php-faq.org/local/115/

pcmt—-

I would say your link was of cogent interest;~) Though it don’t think it brings anything new to the situation its presentation of a desirable set of processing tasks that really ought to be carried out is concise.

Bits of what I have already stop these criminals’ objective (other than that of winding me up and similarly occupying a considerable segment of my time and energy) but nothing appears to kill them outright. This ought to be possible and IMHO it’s the best target for everyone else’s peace of mind.

I’m awaiting some sort of troubleshooter’s script from whooami not least for its educational value on the issue. Meanwhile I’ll have a go at incorporating some of functionality described in your link, thanks!

—-best wishes, Robert

pcmt—-
I’ve shoehorned that stuff in to one of my WP sites. Until I possess some sort of test procedure or script I can’t exactly stress test that area. So I just have to rely on the native live stress testers doing what they do best;~| Not noticed any live differences yet but will keep you posted.
—-best wishes, Robert

churchtown, you should be able to test it by entering a ‘bad string’, eg:

Content-Type (with a semi-colon added at the end)

anywhere in your contact form, and if the script is working you should see a blank page as the script “exits.”

pcmt—-
I’m not a programmer but I think you meant…
Content-Type (with a colon added at the end)
…but the rest of it was just trouble. My site really does not like whatever logbadrequest() is or should do. Had to delete all the iterations of it out of the test php file. From the loops it looks like the test php file just can’t properly cope with the fact that my site has a non www prefix despite the code looking like it could handle or otherwise test for it. Then it kept giving 403 for perfectly ordinary good attempts actually made from the contact form (let alone anything trickly from a command line POST)… so I’ve dumped it.
—-best wishes, Robert

WP-ContactForm fix

https://www.avinashv.net/2005/12/09/wp-contactform-fix/

Not appropriate (site was virtually unreadable with my eyesight).

Yeah, I had to highlight the text just to figure out what it says, and actually the fix hasn’t anything at all to do with this current discussion…. It’s a tweak to make the contact form work with php in safe mode.

churchtown, logbadrequest() is a call to a function that does not exist, so that line should be removed. Otherwise the script should work fine (I’m not a programmer either). You would place it like so:

if (isset($_POST['submit'])) {

(The script goes here)

(Your email script goes here)

}

pcmt—-
You don’t say;~) Anyway that stuff looked self-standing enough to me. So I saved the entire example (between <?php and ?>) as a file named validation.php and called it from the earliest point I could determine in the Custom Contact Me/You plugin. Chose its custom-contact-email.php file and inserted a new line…
?WAS
require_once(‘../../../wp-blog-header.php’);
?NOW
require_once(‘validation.php’);
require_once(‘../../../wp-blog-header.php’);
…which appeared to do the job adequately enough.
—-best wishes, Robert

Robert,

The point of the script I referred to is to try to prevent header injections. It can be tested by entering one of the example ‘bad strings’ into your contact form. The script ‘exits’ when a ‘bad string’ is entered, and a blank screen should appear. (the logbadrequest() function lines must be removed from the script)

I don’t know the plugin you’re using so I can’t say exactly where the script should go, but it should run somewhere between your POST action and the part of your script that actually sends you the contact email.

It is ‘self-standing’ but it has to be called in a location where it acts on the submitted content and not just when the contact page is loaded. If it’s outside the ‘submit’ loop then it won’t be doing anything.

As I say, you’ll know if it’s working when you try a header injection yourself!

pcmt—-
AFAIK all three flavours of contact forms now prevent header injections per se. I don’t know how to “try a header injection” myself. I’ve some guesses in hand by looking at the data that Bad Behaviour stockpiles but I’ve no real idea how to re-use the information myself either directly on my server or via a remote test facility. I would like to be able to test more intelligently than by a method uncomfortably like pointing a loaded weapon at oneself and saying: “Well… am I feeling lucky?”
—-best wishes, Robert

Robert, this might be helpful:

https://securephp.damonkohler.com/index.php/Email_Injection

pcmt—-
Yes, very helpful. I now KNOW that I’m out of my depth. I really shouldn’t be messing with PHP alterations over and above what the original author should’ve been doing… I think it’s going to lead to further problems and/or breaches for which some I may be responsible;~| I’m really not getting very far ahead at all with this issue. Also whooami seems to think there’s something amiss with (my server’s) mod_rewrite functionality which is driving me somewhat nuts as mod_rewrite is desperately important to an Apache server. I may just switch this contact stuff off for all the trouble it’s causing. Thanks for your willingly offered help anyway pcmt.
—-best wishes, Robert