Child pages
  • [security] Another approach to prevent form submission by spiders
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/5dc836fb951a5077#

Today most popular approach is to place captcha code on form to verify, that humans (not search engines) are submitting site forms. More dirty captcha image is, more chances are spider/bot won't be able to recognize it. On the other hand it makes form submitting uncomfortable for users. Also captcha is used only on forms, when user is not logged in.

Here is approach, that is not using captcha, but still provides same level of protection:

  1. after page with form is loaded, then send ajax request to server
  2. in ajax response send random name and random value + save both to session
  3. when ajax response is received, then dynamically add hidden field with received name and value
  4. when form is submitted, then check, that submitted value matches generated one from session

We are generating random hidden field name to allow same form to be submitted from different tabs of same browser, when we have same user session.

Because of spiders don't execute page javascript this approach can work.

Related Discussions

Related Tasks

INP-566 - Getting issue details... STATUS

7 Comments

  1. This is quite interesting idea!

    I guess, the only down site user needs to have a Cookie enabled, but even
    then we should be able to pass SID in Get for verification?

    DA.

  2. Sure, no need for cookies, since session will switch to get mode in that
    case, but still will exist. Captcha also uses session to store generated
    code, so no change here.

  3. Small correction: for correct simultaneous form submissions, two
    hidden fields should be dynamically added, one with name like
    "verification_key" and another with name like "verification_value",
    also this pair is stored on server in session array called like
    "verification_pairs" with "verification_key" as key and
    "verification_value" as value. Then on submission we take session
    array element with passed key and compare passed value to stored one.
    Sure, also we verify that both key and value have been passed, and
    passed key exists in session array.
  4. Thanks Sergey,

    For me both ways sound like going to work - so we just need to decide the
    path we want to go, do the task and move forward. It would be great if we
    can add something like this to 5.1.0 release which mostly developed by
    Alex. For some time he'll be quite busy with some other tasks for 5.1.0
    including minimizing JS and Submission form improvements.

    Would you be interested in implementing your approach on some test form in
    5.1.x branch?

    Thanks!

    DA.

  5. Sergey - no pressure if you don't think you won't be able to participate
    with development here. Even though we'd like to see more of your involvement
    in the project considering your experience with the system :)

    DA.

  6. New task has been filed here:

    715: Replacement for CAPTCHA functionality

    INP-566 - Getting issue details... STATUS


    DA.

  7. The approach described somewhat resembles the CSRF protection token usage, where:

    1. we generate a random token once per session and store it in session of course
    2. on the form we place "csrf_token" hidden field with value from the session
    3. upon form submission we check if "csrf_token" hidden field is present and value matches one from session
    4. if either of above doesn't match ignore the request (means probably Spider does the request)

    This [security] Adding CSRF protection to submitted forms discussion explains this in detail.