Is there any solution to secure forms?

[toplisek]

I have seen solution to be added inside .htaccess.

Is this correct way?
RewriteCond %{HTTP_USER_AGENT} Java.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Java.*
RewriteRule ^/(.*)$ /$1 [F]

Will this protect forms as these Java user-agents are either not interested in identifying their purpose or not ready to publish their name and take ownership of the crawling activities. Both cases are a waste of bandwidth.

Detected browsers:

Java/1.4.1_04
Java/1.5.0_02
Java/1.5.0_06
Java/1.5.0_14
Java/1.6.0_02
Java/1.6.0_03
Java/1.6.0_04
Java/1.6.0_07
Java/1.6.0_11
Java/1.6.0_12
Java/1.6.0-oem


Need help if this code is correct and all other pages will work.

[phranque]

RewriteCond %{HTTP_USER_AGENT} Java.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Java.*
RewriteRule ^/(.*)$ /$1 [F]

in .htaccess or directory context, that target (with a leading slash) won't match any requests.
if the RewriteRule was doing something useful, the RewriteCond directives could be condensed into one rule since one is a subset of the other and the trailing .* is superfluous:

RewriteCond %{HTTP_USER_AGENT} Java

Will this protect forms

what do you mean by "protect forms"?
are you trying to forbid user agents self-identified as "Java" from submitting POST requests?

[toplisek]

We have seen security issue as forms as submitted with blank values even there is jquery validation.
These Java user-agents are either not interested in identifying their purpose or not ready to publish their name and take ownership of the crawling activities. Both cases are a waste of bandwidth.

[wilderness]

If you use any of the off-the-shelf (freely downloadable)PHP mailer forms, it will eventually be compromised by some bot.

There are some versions that were supposed to be secure, however I've not seen one.

My own solution over the years was to simply use rotating (documented with dates) email addresses in the mail form.

[Philosopher]

There are a number of solutions. One of the simplest & best I've found (thanks to someone here at WW) was to create a dummy field and name it something common like "email" or "subject" that you would expect to find on a form...then hide that field via CSS.

If the form is submitted with something in that field, it spam and get's killed...if the field is blank it goes through.

Very simply to implement and has taken care of virtually all my form spam issues.

[phranque]

you could easily send a 403 Forbidden response to any requesting user agent with "Java" in the UA string using mod_rewrite directives.
some modifications to what you already have...

Deny Access to Specific User Agent?:
http://www.webmasterworld.com/apache/3836643.htm [webmasterworld.com]

[toplisek]

I have checked post like:
If the form is submitted with something in that field, it spam and get's killed...if the field is blank it goes through.

As I understand input field like Subject will not be seen to users. Validation will be set as 'requested field is FALSE'

So, if this is blank field it will submit form values. If there is value it will submit field.
You posted:
If the form is submitted with something in that field, it spam and get's killed...

How they submit if this form has hidden field and they submit value as this field is actually hidden?

Do you have an example to do this?
jQuery valiation
[bassistance.de...]

[Samizdata]

How they submit if this form has hidden field

The field is only hidden from humans looking at the form on a screen.

Bots don't have eyes, they parse the HTML markup source.

...

[penders]

...submitted with blank values even there is jquery validation.

Note that any JavaScript/jQuery validation is just front-end "sugar" for your users. All the real validation needs to be performed server-side. The JavaScript validation will simply be bypassed by most spam bots.

One of the simplest & best I've found ... was to create a dummy field and name it something common like "email" or "subject" that you would expect to find on a form...then hide that field via CSS.

Whilst this is great for catching many bots, it comes with an important caveat... it can also catch real users who use form auto-completers (scripts, plugins or built in to most modern browsers). The auto-completers behave like bots and complete the hidden (with CSS) field. This is more likely to happen if you are using a common field name - but, as you say, this is also an important step in fooling more bots. So, it is unwise to treat this as a last line of defence and "kill" the form submission. Perhaps prompt the user with a secondary "human check" (or divert the email to an alternative address if it is a simple mailer)?