Securing forms without captcha?

brendan2b

When designing a php form I am sure everybody wants to make sure that the user who is submitting data is actually on "their site" and not submitting remotely.

Ways of preventing this are captchas and other such ideas to prevent spam. How practical and secure is it to lets say create a hidden field in the form call 'token'. This can be a randomly generated alphanumeric ID of length 10. You store this value in a session variable as soon as the page loads, and when the form gets submitted you check to make sure the token matches your session variable.

Now my question is, does that prevent a user from let's say creating a dummy form on some external site and submitting data over to mine? I have some forms that I do not want to use a captcha on, but I want to make sure the user is on "MY SITE" and not some remote one.

I am trying to find a sure way to prevent the submission of forms from somewhere else without using a captcha.

Any help would be appreciated to shed some light for me on this topic.

Thanks.

laserlight

brendan2b wrote:
How practical and secure is it to lets say create a hidden field in the form call 'token'. This can be a randomly generated alphanumeric ID of length 10. You store this value in a session variable as soon as the page loads, and when the form gets submitted you check to make sure the token matches your session variable.

What would prevent the user from creating a form element with the same name and value in his/her own external form?

brendan2b wrote:
I am trying to find a sure way to prevent the submission of forms from somewhere else without using a captcha.

What is the reason that you are looking to do this?

brendan2b

Yea it seemed to good to be true. I probably should have known that already. For example when a user logs in I don't want to have to ask them to type the text in the image, I just want them to be able to insert their username/password but I want to make sure it is on MY SITE and not coming from an external url.

laserlight

brendan2b wrote:
For example when a user logs in I don't want to have to ask them to type the text in the image, I just want them to be able to insert their username/password but I want to make sure it is on MY SITE and not coming from an external url.

If you want to deter a brute force attack, introduce a short delay for each login attempt, or place a cap on the number of failed login attempts before some longer delay is imposed, or introduce a CAPTCHA after a few failed login attempts (so users can normally login without bothering with a CAPTCHA, as seems to be your intention).

lazzerous

Another thing you may want to implement, as an added (not end-all-be-all) measure, is to initialize a session variable on the form page that must be present in the submission handler script in order for it to process. This way it cannot be duplicated remotely.

laserlight

lazzerous wrote:
Another thing you may want to implement, as an added (not end-all-be-all) measure, is to initialize a session variable on the form page that must be present in the submission handler script in order for it to process. This way it cannot be duplicated remotely.

The user would not need to duplicate the session variable since the user can load the form to get the session registered (and the value set), and then submit his/her own version of the form.

dalecosp

A recent article in c't (a German magazine) condemns CAPTCHAs as too easily foiled by todays bots (with OCR technology) and suggests the following ideas for bot evasion instead:

Provide a form input field like "street address" or something similar that you don't actually need, and make it invisible to a legitimate user. Bots tend to fill in ALL fields, so you'd write your handler to reject any forms that contained data in the hidden form field.
A similar trick is to hide a form field in an HTML comment; many of the bots tend to ignore comment delimiters as well.
A third trick works in the opposite way; use Javascript to create an "on the fly" form field that isn't in the actual HTML output. Most bots tend to not execute Javascript.
Beyond that, dynamically created random form fields and cryptographic signatures, time stamps, etc. are more advanced means to bot blocking.

HTH, (and thanks to Olli Fromme for the info)

foyer

Those are good tips