Spam and CAPTCHA?

[ayok]

Hi,

 

I make an online form which is sent the data to database and my email. There are about 10 questions like name, surname, birthday, and textarea for message. For some fields, i put js validation ask that some fields has to be filled in. Furthermore, I put this script:

	if (eregi('http:', $msg)) {
	die ("Send us no link! ! <br><a href='index.php'>back</a>");
}

So the textarea cannot be filled with a link to other website.

 

My question is, do I still need to use captcha in order to avoid spam? I am afraid some visitors will be annoyed by captcha.

 

Thank you,

 

ayok

[monkeytooth]

Personal Opinion.. but spam is what spam is, someone will always work around it some how some way.. despite the annoyance of things like captcha in the way. So one way or another spam will hit your site/forum/whatever. and you will always have to go through and periodically check and delete manually somehow. At the risk of sounding like a jerk through chances are if you have to ask do I think I should implement it chances are its not a big enough problem to worry about captcha right now, and better off to just not deal with the frustration of working it in... It's a Good idea though none the less more so if your sites going somewhere, but if its going somewhere then why worry about the users being bothered with captcha. I would think users would enjoy a site thats clean and clutter free of spam then not..

[PFMaBiSmAd]

A CAPTCHA does not prevent spam. What it does do is stop a large portion of automated form submissions (in addition to inconveniencing your legitimate visitors and preventing some of them from submitting the form.) A CAPTCHA only requires that someone or a script be able to figure out the answer to the CAPTCHA and enter it. If they are willing and able to enter the answer they can still put spam content into the other form fields.

 

There are several common spam abuses of submit forms - 1) Content that contains links and other spam like content that just gets posted to a web site, such as in a guest book/blog/comment form..., 2) Content that gets sent through your email server where header injection allowed the content to be sent to any number of email addresses that were entered in the form, 3) Content that is placed into databases where sql injection allows someone to take over, and 4) Content that is placed into files (or uploaded) where script is then executed to allow someone to run their code on your server.

 

Trying to detect "http" only addresses part of the first type of spamming.

 

Note: "http" can be encoded using html - &# 104 ;&# 116;&# 116 ;&# 112 ; (without the spaces) or &# 72 ;&# 84;&# 84 ;&# 80 ; (without the spaces) or using any combination of upper/lower case html encoded "http" or any combination of real letters and html encoding - htt&# 112 ; (without the spaces) is the same as "http".

 

Also note: For email header injection, html encoded characters can be used to enter things like "Bcc: spam@your_email_address.com, spam@someone_elses_address.com". BCC: looks like - &# 66 ;&# 99;&# 99 ;&# 58 ; (without the spaces) or any combination of html/upper/lower/real characters that make up "Bcc:"

 

So, it would be necessary to detect if html encoded characters were being used as well.

 

Your form processing code is the last line of defense. No matter if you have a CAPTCHA or not or how good your CAPTCHA is (read this link to find out how easy it is to decode an image CAPTCHA - http://www.ocr-research.org.ua/index.html), your form processing code must detect and prevent spam as it is the last step in the process.