Robots using my contact forms!!! 1

[Sleidia]

I've noticed recently that what seems to be robots or worms or whatever send me spam via my contact forms on my websites !

The first time, I thought it was a spammer who used the form manually but it happened so many times that I ended doing a research on google with "baiduicp@hotmail.com" which made me understand that I wasn't alone to be persecuted

So, programatically speaking, what should I do to prevent such a thing to happen again?

Thanks !

 

[jpadie]

use a CAPTCHA glyph.

if you have pear installed use pear::Captcha.

if you don't then just google for "php catpcha" or use the hotscripts search etc. there are plenty of classes out there.

 

[Sleidia]

Well ... I don't find it very user friendly

Plus, I'm just reading this on wikipedia :

Automated attacks on CAPTCHAs are also growing more sophisticated. Projects like PWNtcha have made significant progress in defeating commonly used CAPTCHAs, which has contributed to a general migration towards more sophisticated CAPTCHAs.
This Microsoft research paper -

http://www.ceas.cc/papers-2005/160.pdf

- found in 2005 that computers are now better than humans at solving CAPTCHAs based on alphabetic characters.

Maybe a simple browswer language detection would do the trick?

 

[jpadie]

Well ... I don't find it very user friendly

what don't you find user friendly?

you can still easily beat a robot using a simple glyph. just have the user type the glyph characters backwards.

 

[Sleidia]

To me, a better alternative would be one that spares the user from doing additional tasks. Something transparent to the user, I mean.

A simple solution that comes in mind could be the use of a cookie. If the cookie isn't saved, no message is sent.

Maybe we can come up with something better?

... like counting the time elapsed between the user's arrival and the instant when the message is sent. This one looks safer don't you think?

 

[sleipnir214]

A simple solution that comes in mind could be the use of a cookie. If the cookie isn't saved, no message is sent.

I think it would be trivial to create a spambot that, as well as use your form to spam you, will make use of whatever cookies you throw at it. For all we know, it already does.

... like counting the time elapsed between the user's arrival and the instant when the message is sent. This one looks safer don't you think?

I don't know. Is it your goal to merely slow him down, or to stop him?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[Sleidia]

I simply think that there is always a better solution.
Bothering users with additional tasks isn't a good solution in my opinion.

It sounds logic to think that robots are designed to do their job as fast as possible. I doubt that a robot would ever wait 30 seconds on my contact form. But what do I know

 

[sleipnir214]

I also doubt that your users would ever want to wait 30 secons to use your contact form. I know I'm generally not that patient.

There is no way I know of to tell a bot website user from a human website user without some kind of test of cognition.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[azimuth0]

They aren't just sending you spam. They're trying to exploit a common vulnerability in contact forms to send others spam using your form.

Many times, simply detecting the exploit attempt and blocking it will be enough to halt the flow. Modify the code (or have someone else modify it) so that name or email fields are checked for newline characters. If there's a newline character, it's certainly an attempt to send spam via your server.

: Daniel :

-

http://www.bitmuse.com/

 

[Sleidia]

I also doubt that your users would ever want to wait 30 secons to use your contact form. I know I'm generally not that patient.

I said : 30 seconds between arrival on the website and form submission.
This would also spare me from one-liners that I certainly don't need. Same for the copy/pasters.

Modify the code (or have someone else modify it) so that name or email fields are checked for newline characters.

I'll do that too.
Should I detect \r as well or only \n would suffice?
Thanks !

 

[richcleverley]

I am having exactly the same problem - 40 came in last night alone. They seem to have various email addresses input in them including false ones from my own domain.

The glyph idea is one I was thinking of but I have never implemented such a thing before.

Richard

 

[theEclipse]

Not that this solves the programmability of implementing the glyphs in a contact form, but I would like to make a vote for using them.

Even though, as Sleidia's quote states, machines can be better at solving these glyphs than humans, the problem is then in the hands of the spammers. The problem with OCR technology is that it takes too much time. Spammers want to be able to send out email in batches of thousands in as little time as possible -- setting up an OCR script to find and recognise the characters in a glyph steals valuble processor time.

Simply put: if you were a spammer would you target an email form that takes 0.03 sec/email or one that takes 0.09 sec/email? The 0.06 sec/email is about = 60 sec for 1000 emails. The times are guesswork, but the point is valid.

Furthermore, the case study referenced above limited the generated CAPTCHAs to glyphs with a standardized number of characters and near-standardized locations of the characters. In other words "When solving the recognition problem, the segmentation problem is assumed to be solved" This also proved to be the most difficult problem of multicharacter glyphs--finding the characters.

My point is, even though machines can be better at recognizing these characters, a spammer would be much less likely to implement an OCR algorithm to send spam on a public contact form than they would be to just find another form.

Robert Carpenter
Remember....eternity is much longer than this ~80 years we will spend roaming this earth.
ô¿ô

http://www.robertcarpenter.net

 

[Sleidia]

Well guys, you keep talking about how secure CAPTCHAS are compared to other forms of protections but I find it quite weird that none of you try to think on the users side.

Securing something is one thing but doing it by bothering the users is another thing.

Not to mention that sometimes, characters are nearly unreadable.

But as the previous poster said, spammers goal is to do their stupid job as fast as possible. This is the reason why I think the time counter might be a good option.

 

[sleipnir214]

Sleidia:
I am an internet user as well as a programmer. There are nearly a dozen sites I go to every day that use CAPTCHAs to determine that a human is interacting with the site. I have no problems dealing with this, and if it slows me down at all, I haven't noticed.

And you are forgetting that a spammer's bots hit thousands of sites simuntaneously. Implementing a 30-second wait is meaninful only for a single user -- if you're doing this in parallel, it's a simple matter for one thread to to start the counter and another to finish the interaction. For that matter, it's not a matter of wait time, it's a matter of processor time. CAPTCHAs cause spammers' computers to devote lots of processor time to OCR.

And the readability of a CAPTCHA graphic can usually be tweaked.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[Sleidia]

...it's a simple matter for one thread to to start the counter and another to finish the interaction....

Forgive me for this silly question but aren't PHP sessions supposed to be unique for each thread?

 

[sleipnir214]

No.

Session variables are unique to each session index cookie provided by the browser. Two spammer-threads could easily share cookies.

After all, if you have multiple IE windows open, they can share cookies....


Want the best answers? Ask the best questions! TANSTAAFL!

 

[Sleidia]

Ok but, if the counter is reset to zero each time a "user" enters the page, then the problem is solved. If, as you said, two spammers share the same sessions, then they will both be reset to zero.

 

[sleipnir214]

Again, no.

You're forgetting that web applications are discontinuous. A browser issues a GET request to a server, the server runs the script, the server channels the output of the script to the browser. Then the script stops running and the connection between the browser and the server is broken.

If you start the clock every time a user connects, then your user will connect, starting the clock. But when the user then submits the form, it will restart the clock because the web browser must open a new connection to the server to submit the form's data.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[Sleidia]

You lost me
But I think that you misunderstood what I want to do.

On arrival on the page => get current time and store it in a session variable.
Upon form submission => compare stored session variable with current time and check whether or not 30 seconds have passed.

Getting the current time on every arrival = resetting the counter to zero.

There is nothing continuous in this, I think.

 

[chipperMDW]

Securing something is one thing but doing it by bothering the users is another thing.

Unfortunately, security is usually inversely proportional to convenience. We've been "bothering" users with passwords for quite a while, now.

From an accessibility standpoint, consider what happens when a blind user comes across a CAPTCHA. Is there any CAPTCHA equivalent that relies on a different sense than sight?