We have a front end form that allows the user to update their own profiles. This has been hacked for the second time – it only seems to be the text/textarea fields that are hacked.
Here’s my code below, is there any way to stop this from happening?
An example of a page is this, below the organisation title is the textarea field that outputs the profile.
<?php $company_information = array(
'post_id' => $post->ID, // post id to get field groups from and save data to
'field_groups' => array(162), // this will find the field groups for this post (post ID's of the acf post objects)
'form_attributes' => array( // attributes will be added to the form element
'class' => ''
),
'return' => add_query_arg( 'updated', 'true', get_permalink() ), // return url
'html_field_open' => '<div>', // field wrapper open
'html_field_close' => '</div>', // field wrapper close
'html_before_fields' => '', // html inside form before fields
'html_after_fields' => '', // html inside form after fields
'submit_value' => 'Update', // value for submit field
'updated_message' => '', // default updated message. Can be false to show no message
); ?>
<?php acf_form( $company_information ); ?>
Hi @robteamworks
What do you mean by ‘hacked’?
Thanks
E
Thanks for getting back to me @elliot.
We had some genuine text that was output in the usual way, this had been replaced on several pages by spurious text, arabic etc etc. Just general stuff you tend to get in spam comments.
We have several other fields on the page with the front end forms that weren’t touched, it only seemed to be the text and textarea inputs.
Out of 140 custom posts, there was at least a quarter of them hacked with very similar text.
We have the WP Security plugin so everything apart from this is very secure. We’re very certain they’re getting in via the front end form text/textarea fields somehow.
Hi @robteamworks
Is it possible in your code that a GET parameter could be modified to allow an update to an existing post? perhaps some sort of post_id parameter?
Hi @elliot,
I’ve been looking into this a bit more. I don’t have any forms on the page apart from what is generated by the acf_front_form so no GET’s etc of my own.
First and foremost I noticed a hole in my code – I have the edit forms set to display:none; by default, if the user logs in and goes to their profile then little icons appear allowing them to unhide the front end form and thus edit their profile. The bit of code that was wrapped around the icons to check if they’re logged in wasn’t wrapped around the front end form as well. This meant that the form was there but hidden regardless of whether you were logged in or not.
So I’ve now wrapped the code around the form as well so that was more than likely the way the spammers were hitting the form all the time.
So the fact they have to create an account before they can spam the fields may deter them but it doesn’t really solve the real problem.
I’m not really sure what the solution is but if you take out all the checks to see if someone is logged in or not then the front end form can be hit with spam.
This then points to the usual ways to stop form spam such as Captcha’s, honeypots etc etc. I know those are not ideal but at the moment the front end forms are wide open to spam.
Cheers
