Form Spam Reduction

[The Little Guy]

I was thinking of a way to reduce website spam.  Since spam is submitted through web forms, I was thinking:

 

1. Use PHP to generate a JavaScript form, give the inputs random names.

2. Use the JavaScript generated from the PHP to display the form on the page.

 

What are you thoughts on this method?

[PFMaBiSmAd]

There are browser macro's that allow automated spam to be easily setup by anyone and sent using an actual browser and your actual form.

 

As has been posted before, as long as form processing code does not validate all input to detect spam content, spam content will get posted or sent through email using that form processing code. The form processing code is the last link in the chain and it must be the strongest link. Anything you can do to the form can be discovered and bypassed, or in the case of the browser macro's, no one really cares what you do to the form, because the form is sent to the client and it is out of your control at that point.

[The Little Guy]

can you explain form macro?

 

I read this:

The iOpus iMacros plugin for FireFox might help you. You can create one macro, edit it to work on multiple sites, and hit "go." The trick is, each site must have the same elements so the macro can find the fields to place text in.

 

but since elements have different names every time the browser reloads the above macro wont work with it (I think).

 

Do you know of any info, or strategies of how to "detect spam content"?

[corbin]

If someone was really desperate, couldn't he/she just parse the JS?

[The Little Guy]

If someone was really desperate, couldn't he/she just parse the JS?

 

Yes, but... you could make the JS hard to read, and you could do some htaccess to make it so it can only be read if the user is referred to the js page, and you could check if the user comes from your site or another site.

 

The harder it is to hack the less spam I hope to get

[corbin]

Referer is one of the easiest things to fake in HTTP.  lol.

 

 

 

Worst case, couldn't you just actually parse the JS?  cscript, or what ever engine a browser users, or some other variant.

[The Little Guy]

Referer is one of the easiest things to fake in HTTP.  lol.

 

It is still a road block for them to get through. Also, couldn't I make my own headers and require a HTTP referrer? When the JS is requested from browser the site would be requesting from "http://h21jde04jo9f.mysite.com" (for example) every time. getting that EXACT referrer would be very hard for a hacker to find... Unless there is a program that can watch what headers are being sent.

[corbin]

"Unless there is a program that can watch what headers are being sent."

 

 

I don't think you understand how HTTP works x.x.

 

 

You can't magically hide something that you send to the client.

 

 

Very worst case, the person could just request page A, so he/she would have the secret for page B.

 

 

 

Or am I misunderstanding what you're talking about?

[The Little Guy]

You maybe. I'm not sure.

 

lets say that you have your site (A), and your JS (B (first parsed with php before sent to browser)).

 

1. "A" requests "B" in the browser.

2. "A" sends a special HTTP REFERRER to "B", such as "http://8djd8djd8kd.site.com" if the referrer matches that send back "B" in a JS format, else send back an error message.

 

Now after typing this, I just realized that firebug can still parse the JS.

[corbin]

A website doesn't request JS; a browser does.

 

JS isn't [usually] parsed with PHP.  It could be, but I don't think that's what you meant.

 

I don't think you get how a Referer header works.  I think you have it backwards.

 

 

Let's say my browser requests somesite.com:

 

GET / HTTP/1.1
Host: somesite.com

 

Then the server on the other end returns

HTTP/1.1 200 OK

<a href="something.html">Somelink</a>

 

Then I click on Somelink in my browser.

 

 

My browser would choose to send the Referer header in the next request:

GET /something.html HTTP/1.1
Host: somesite.com
Referer: http://somesite.com/

 

 

For a server to send a referer header wouldn't make sense, and for JS to set a Referer header wouldn't make much sense either.

 

 

 

Perhaps I'm still misunderstanding?

[The Little Guy]

if you take this link (I made this):

 

http://dudeel.com/statistics/javascripts/stats.js

 

if you click on it, it works, but if you type it into the browser, it doesn't work.

 

Im talking about something sorta like that...

[corbin]

Open up either cmd or terminal.

 

type the following in, exactly:

 

telnet dudeel.com 80
GET /statistics/javascripts/stats.js HTTP/1.1
Host: dudeel.com
Referer: omgthissitedoesntexist29381903.com
Connection: close;

 

See?  Referer isn't very hard to fake.

 

By the way, if you go straight to http://dudeel.com/statistics/javascripts/jsProcess, it shows a lot of full paths.

[The Little Guy]

TY, Not any more

[PFMaBiSmAd]

Anything you can do to a form can be un-done by anyone willing to put in just a little more effort and time than you did when you came up with the idea.

 

The most effect way of preventing an automated bot script from submitting to your form processing code is using a good CAPTCHA. If you have a good CAPTCHA and are still receiving spam it is likely that a real person(s) are submitting the spam.

 

The way to prevent your form processing code from accepting spam, no matter how it is being submitted is if your form processing code detects the content in the data that is spam and discards the submission. Or as has already been suggested before, submissions by non-members should be fully moderated and reviewed by a human before being posted on the site.

 

If you already have a CAPTCHA and the normal tricks used in a form to prevent automated spam and you still have spam, you are sort of barking up the wrong tree by trying to fix the problem in the form. The fox is in a different tree.

[VBAssassin]

One way around it is to dynamically change the names of the fields sent. This confuses the macros because each time they try and fill in the form, the names and id's etc of the fields it's supposed to access change! Meaning it's then bust.

 

It's a pain to implement dynamic names though, such as:

 

Page Hit 1

<input name='dsafd'>

 

Page Hit 2

<input name='2133dsas'>

 

Page Hit 3

<input name='a8s7sjd'>

 

Since the real names have to saved as well:

 

<input type='hidden' name='_a8s7sjd' value='title' />

 

Once the form is sent, your post data is scanned for all the names beginning with _ (these for a hash, or in php, associative array). You then lookup each of the dynamic names in the table to work out what data is what from the dynamic form.

 

This will prevent your script from getting confused, but not the macro script (except macro scripts that automate mouse movements and clicking etc but then you have to give up your mouse while the macro runs).

 

Kind regards,

Scott

[The Little Guy]

VBAssassin, that was in my first post! I think the idea would work... but only like PFMaBiSmAd said that it would be submitted by actual humans.

 

I was doing md5, and then just gettting the post vars... I just need to know the order they were send through. (top-bottom I'm sure).

 

 

PFMaBiSmAd I only want to have a CAPTCHA when the user registers. Is that a good idea?

 

 

Note: I don't know if I care if the method(s) used to help stop spammers completely, but also adds a roadblock to their spamming (I wan't to make them jump through lots of hoops).

[corbin]

One way around it is to dynamically change the names of the fields sent. This confuses the macros because each time they try and fill in the form, the names and id's etc of the fields it's supposed to access change! Meaning it's then bust.

 

It's a pain to implement dynamic names though, such as:

 

Page Hit 1

<input name='dsafd'>

 

Page Hit 2

<input name='2133dsas'>

 

Page Hit 3

<input name='a8s7sjd'>

 

Since the real names have to saved as well:

 

<input type='hidden' name='_a8s7sjd' value='title' />

 

Once the form is sent, your post data is scanned for all the names beginning with _ (these for a hash, or in php, associative array). You then lookup each of the dynamic names in the table to work out what data is what from the dynamic form.

 

This will prevent your script from getting confused, but not the macro script (except macro scripts that automate mouse movements and clicking etc but then you have to give up your mouse while the macro runs).

 

Kind regards,

Scott

 

 

It wouldn't be very hard to parse out the fields.  Or would their order change?