spammer/hacker on CF form

[Guest]

I have a bunch of forms that email the results to the contact person. Recently we have received tons of emails that seem to be from a spammer or hacker possibly. All of the emails are similar which makes us feel that they may have somehow automated this. The first, middle, and last names are separate fields. When we get the email, they are each filled in with the same name. The email addresses (from the field) are always some name @yahoo.com. All of the results that we got had the city field entered as Moscow and the comments all said the same exact thing and linked to porn sites. We've gotten at least 100 emails since Friday. And they don't just happen on one form..they are spread out.

Has anyone else experienced anything like this? How are they doing this? Is there anyway to get around this? We were thinking doing a cfif statement to see if fname and lname and mname are all the same to send an error message. Any ideas?

[craigkaminsky]

Sounds like your form processing page/script was hijacked. This, sadly, is not too infrequent. There are several things you can do to try and prevent this from happening.

1. Use "CAPTCHA" (those funky images with garbledy text people have to type in to process the form) -- Do "coldfusion captcha" search on google and there's a lot to be seen.
2. Post some of your form and processing code. There might be some basic steps we could help with in order to protect the form. Little things, like making sure the form is posted or if the referrer is actually from your site, etc.).

Cheers,
Craig

[Guest]

Thank you! I will certainly look into that.

For our forms...we first cfparam everything to be blank. The very first param is <cfparam name=page default="0"> and at the end of the params we <cfset errmsg="">

Then we do the error checking to make sure the required fields have data in them:
<cfif fname is "">
<cfset errmsg=errmsg & "Please enter your first name. <br>">
</cfif>

Then:
<cfif errmsg is not "" or page is 0>

<cfif page is not 0>
<cfoutput><font color=red>#errmsg#</font></cfoutput>
</cfif>

<cfset page = page+1>
<cfoutput>
<form> Then all of the form is inserted.</form>

<cfelse>
If going into a db, the query would go here. This particular form was not set up to go to a query. So it continues with outputting the results...

<cfoutput>
First Name: #fname#
</cfoutput>

<cfmail>
Here we have the results email the contact person.
</cfmail>

</cfif>

I hope this isn't too confusing!

[craigkaminsky]

Nope. Makes total sense :).

One thing you can do on your form processing page is to surround the processing code with a conditional that tests to ensure the form was submitted (I'm assuming you are using method="post" in your form).
<cfif Lcase(Trim(CGI.REQUEST_METHOD)) is "post">
<!--- process form code --->
</cfif>

This makes sure that the form values are posted to the page and not included in a URL string or something else.

Also, you can play with the value of CGI.HTTP_REFERRER to see if you can ensure that the form processing page is being accessed from the form and not an external script. This, in my opinion, is most effective when your processing page and form page are separate.

For example. let's assume that your form page is:
http://www.yoursite.com/myform.cfm

On your processing page, you could try something like this:
<cfif lcase(trim(cgi.request_method)) is "post"
AND cgi.http_referrer contains "www.yoursite.com/myform.cfm">
<!--- process the form --->
</cfif>

Neither of these would offer the security of a captcha-enabled form but they may very well help weed out some hijacking attempts. The cgi.http_referrer can, at the least, make it harder for the hijackers because they would have to either manually submit the form from your web page or spook the http_referrer value. Not impossible but it should weed out a good deal of the automated hijacking that goes on.

I'd definitely be interested to hear what others do to protect their forms, too!

Cheers,
Craig

[Guest]

quote:

---

Originally posted by: craigkaminsky
Nope. Makes total sense :).

Also, you can play with the value of CGI.HTTP_REFERRER to see if you can ensure that the form processing page is being accessed from the form and not an external script. This, in my opinion, is most effective when your processing page and form page are separate.

---

I wouldn't count on this. cgi.http_referrer can be spoofed so your form thinks it is coming from your server.

[Guest]

This does nothing for an automated hijacking, but I show the form-filler's IP and the time at the top of the form, to indicate that it is being recorded. Also, for certain applications, I have a wait-time. A daily glance at the sorted-by-IP waiting list shows up problem IP's, which I then put into a blacklist. (This is a normally low-volume application).

In fact I was just going to post a question, and still will separately, as to whether anyone knows of a dynamic reverse IP look-up. The IP name associated with some of my trouble-makers is ''.

[Cole · Accepted solution]

Most hackers aren't going to waste time pounding your mail script unless it is vulnerable. Check to make sure that you are not passing unchecked form fields directly into your cfmail tag. Something like this will get attacked for sure:

<cfmail to="#form.toAddress#" from="#form.fromAddress#" subject="#form.subject#">

All the attacker has to do is slip in a crlf and they can craft the email headers any way they want. All the header fields are vulnerable (to,from,subject). Validate all the data before you pass it to the cfmail tag.

peace

-ac

[Guest]

Thanks for your replies. I came across something last night that mentioned passing a hidden field. If the hidden field is filled in, then cancel or keep the form from submitting. Any ideas on how to do this? I made a hidden field and was thinking of making an cfif statment to say that if the hidden field was not blank, send it to our homepage or something.

[craigkaminsky]

On the processing page, you could do:
<cfif IsDefined('FORM.hiddenFieldName') AND FORM.hiddenFieldName IS 'x'>
//process code
</cfif>

If you go this route, keep in mind that the hidden field is visible in the source code. Of course, that would mean that the hijacker or their code would need to scour the source code for hidden fields but it's something worth keeping in mind.

[bradwood.com]

I tried the hidden field trick, IP filtering, and other stuff, but my spam didn't stop until I put captcha in. Then it stopped dead.
Keep in mind, captcha doesn't HAVE to be jumbled letters and numbers. It could be a picture they have to identify, a math problem they have to solve, or even a sould the listen to. Of course, the harder you make it, the more annoying it will be.
I used Mark Mandel's Captcha.cfc. CF 8 wil provide catptha as part of the new cfimage tag. Yeah!!

~Brad

[tclaremont]

For a while I just had a text box with the instructions to type the word "foobar" or some such thing. I spelled it out right on the page. If that text box said anything other than "foobar" when the form was submitted, it did not get processed. You could even use a random function that said "Type #Dayofweekasstring,Now()# in the text box before submitting."

Most of the hijacks are not live people sitting there submitting forms. Even changing your default field names to something obscure will help keep some of the autobots from sending data and having it match your fields.

[craigkaminsky]

I totally agree, Wil. Was only mentioning it as a possibility/option and, as Brad notes, captcha is really the best of available options.

[blackandwhite]

I've been getting the same spam. I've just implemented an IP address look-up and log, I log each IP address (max 5, could be more) and do a compare on this list each time the form is submitted, if your IP address is in the list it won't submit the form. Once the 5 IP's are logged it auto deletes and starts again.

The idea was to stop post after post after post, this way they have to spoof the IP each time, or disconnect and reconnect if they have a dynamic IP. Reduced the spam on our server from 50-60 a day down to 3-4.

Am going to look into Capcha next though.

Trevor

[Guest]

Thanks everyone for your input!

For the hidden field, I need to clarify. I don't mean type=hidden. I mean have a regular field and use css or something to make it invisible to the normal user. If that form is filled in, it wouldn't process the code.

We thought about captcha, but don't you have to pay for it? Was I misinformed? Someone gave me a website and you had to pay for it.

[craigkaminsky]

The image.cfc open source project has captcha feature.

You can download the source code and a captcha example at:
http://www.opensourcecf.com/imagecfc/download.cfm