03-21-2007, 11:25 AM
I'm trying to configure a captcha verification module (originally got from phpclasses.org) for my registration page.
The image is generated by a php file (example_02.php) which is placed as an src of an img tag
and that php file includes a class file. The string is generated from the 47th line of the class.
I'm trying to store the string in a hidden variable so that i can check the value when i press submit.
I'm attaching a zip file, because i have no other way to explain my context in a broad way (sorry for the inconveniences).
Please inform me if I'm going in wrong direction...
03-21-2007, 03:58 PM
You would store this in the $_SESSION variable for instance. I don't think there are hidden variables, unless you mean hidden input (HTML), which is not exactly hidden. ;)
03-21-2007, 04:04 PM
no wouldn't do that if i where you,
cuz if i were a bot,
i would happily read your page's source for the key ;)
03-22-2007, 08:47 AM
many thanks ....
i got my mistake when thought about the problem deeply...
the captcha validation should be done from the server side, not from the client side.
Could you please suggest a method to reliably verify that all the POST data are coming from a page located in my host? (I think I can secure my database from spam. please inform me if I'm wrong...)
03-22-2007, 03:45 PM
Could you please suggest a method to reliably verify that all the POST data are coming from a page located in my host? Form data actually comes from a browser (or a script.) When a browser visits your form page, the form tags are sent to the browser and it renders the form. If someone fills in the form and submits it, the information the browser (or a script) provides back to the server, is the only thing that ties the form page to the form processing page. Someone can, for example, copy and paste your form code into their own file and run it on their server. So long as the action="..." url points to your form processing code, they can submit data to your code.
So, the only things that can tie the submitted data back to your form page would be a cookie, a session variable, or hidden fields in the form. Both a cookie and hidden fields can be "seen" by the visitor, so it is simple to pass any value they contain (even if it is a random value that is different on each visit) back to the form processing code. That leaves a session variable. This is where the function of a captcha comes in.
The random value of the captcha, that is different on each visit, stored in a session variable, and destroyed after being used once, IS the most reliable way to determine that the visitor started on your form page and is a person submitting data to your form processing code. The captcha then needs to be constructed so that automated OCR cannot determine the value (while remaining human readable.)
(I think I can secure my database from spam. please inform me if I'm wrong...)If you have a problem with spam content being injected into your database (or being sent through your mail server), you must close the loop holes in your code that is allowing the spam content. Remove the benefit that the spammer is receiving, and he will go elsewhere. Just adding a good captcha to your form, won't stop someone if they are determined. If they are receiving a big enough benefit from doing so, they will manually enter the captcha value if necessary.
Edit: Something like a captcha, just addresses a SYMPTOM (being able to automatically submit data to form processing code.) The actual underlying problem is that the submitted/uploaded data can either be injected into a database (probably becomes content on a web page), injected into an email header (sending spam to anyone you want), or uploaded (either replacing your content or placing a new file on your server with any script/image in it that anyone wants.)
So the real solution is to FIX the underlying problem that is providing the benefit to the spammer and you won't actually need a captcha.
03-22-2007, 05:17 PM
I think he just wants to stop spam like comment spam/topic spam. I don't think he's worried about injection attacks.
03-24-2007, 12:44 PM
Thanks CFMaBiSmAd for a very detailed reply, you are great!
and thanks to all other who helped me.
I'll use a captcha for user registration and session for all other pages where a user post something after login.