University Web Developers

University Web Developers

Recently we have begun to experience an increase in spam generated from some of our web (HTML) forms. How do you deal with this? I'm concerned that some solutions may be inaccessible (I.e. CAPTCHA).

Views: 117

Reply to This

Replies to This Discussion

nice.. I was not aware that this was available.
I got the idea from someone on uwebd. It's worth twice the price of admission!
You're all wrong, you need to apply the Land Before Time method!
The W3C has an interesting piece discussing this issue.
We are experimenting with the recaptcha API for some of our forms. The audio feature of it was quite appealing. It may not be a system wide solution, but to us it was worth a look.
http://recaptcha.net/learnmore.html
Another interesting method I have seen is to add
enctype="multipart/form-data"

to your form and check for that when processing. I guess most bots don't know to change their encode type. Granted this is another short fix till they decide to do that.

The other ones I know of are mostly Javascript based which I won't use on the off chance they don't have it enabled.
I recently tried a concept that seems to work well. It's based on the fact that most bots only visit a form page once, so that it can harvest the form and all its field names, action URL, etc. This info about the form is then stored in their database somehow, and is then used to constantly hammer the action URL by sending values for all the fields.

(Before continuing, let me say that I took a pretty detailed look at my server logs, found IP addresses of bots sending form spam, and discovered that those IP addresses were not actually visiting the form page itself. They were only submitting to the action URL.)

So, knowing this, I created a method that logs the IP address of every visit to a form. So when you visit a web page with a form on it, your IP address is logged, and you now have permission to actually submit the form. Then I changed my form handling program to check the incoming IP address against that log, to make sure that it has permission to submit the form.

In other words, you're not allowed to submit a form unless you actually visit the form web page first. Most bots do not visit the form web page first, and therefore most all form submissions are now coming from humans.

The main reason I like this solution is that it's all server-based. No javascript. No CAPTCHA. Nothing extra for users to do. And I got fantastic response from the form submission recipients. Form spam dropped to virtually zero!

Then came a problem. A number of visitors started reporting that they could not submit our forms. After investigating IP addresses, I found that they are all AOL users. It seems that AOL is doing some stuff with their IP address allocation, so that a user's IP address can actually change during their online session. This of course throws my whole theory out the window.

So, I currently have this whole thing turned off, and I'm hoping to figure out a way to still use it. I figured I'd post it here anyway, with the hope that maybe someone else can expand on it with a good idea.
Scott,

AOL uses proxy servers that make many users look like one IP address and, as you discovered, makes the same user look like different IP addresses sometimes.

You can check the referrer in the script for the action url to verify it came from the form page and achieve about the same amount of security without all the extra work; and avoid the AOL problem. Referrers can be spoofed, but so can IPs.
Most the bots I have dealt with are smart enough to spoof the referrer so that method hasn't been that fruitful for me.

Though Scott I think a better was to handle your situation is instead of putting an IP address in your DB, make a random seed and put that in the DB and place it in a hidden field in the form. After the person submits the form delete it from the database (to remove the chance you later generate the same seed and the person can't submit) and now when the bots attempt to keep doing it they won't be able to.

I think that method would fix the issues had with the previous solution.
Interesting, very interesting Richard. That seems to make sense. I'm definitely going to think about that a bit.
Yeah, when I did my initial look into the form spam in my server logs, I found a lot of spoofed HTTP_REFERERs. Their initial harvesting process just logged the URL of the original form and simply sent that with the form submissions. I know that IP addresses can be spoofed too, but after banging heads with a couple of other IT minds, we figured that using IP address is more reliable (less spoofed).

I also know about AOL's caching system (as well as the ability for any ISP to do the same). But I only thought that the risk would be multiple visitors with the same IP address. What I didn't realize is that an AOL user doesn't use the same cache server throughout the life of a single online session, hence the possibility of changing IP addresses.

I still like my original concept of insuring that a user actually visits the form first before submitting. I like a couple other ideas posted here too.
I haven't had a chance to try it yet, but the honeypot method seems to be working pretty well for people.

http://www.modernblue.com/web-design-blog/fighting-spam-with-css/

Or the simple question method:

"Please enter the letter a in the box at left."
http://www.subtraction.com

I've also seen, "Is ice cream hot or cold?"

Unfortunately, I don't think I have the ability to do any of this on the server site within our CMS.

RSS

Elsewhere

Latest Activity

Sara Arnold commented on Lynn Zawie's group OmniUpdate
"Here’s an outline of everything you need to know about OCR compliance, including what it is, what your college or university can do to stay compliant, and resources for OCR compliance. #accessibility http://bit.ly/2rcPDgG"
Friday
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Join us for our next webcast with April Buscher from Montana State University Billings to learn how blind readers and people with hearing impairment view and read your website and how you can make it accessible to them. http://bit.ly/2zhdcIt"
Aug 14
Amanda Lawson joined Lynn Zawie's group
Thumbnail

OmniUpdate

Share your experiences using OmniUpdate CMS
Aug 9
Amanda Lawson posted a photo

Amanda Lawson

Amanda Lawson, Web Content ManagerCommunity College of Allgheny County
Aug 9
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"High schoolers spend more time on their digital devices than they do sleeping, doing homework, or participating in extracurricular activities. So how do you make your message stand out to them? #eexpect http://bit.ly/2MOIIWC"
Aug 8
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Want to increase digital engagement with high school juniors and seniors? Join our next webcast with Stephanie Geyer from Ruffalo Noel Levitz as she shares new data from the 2019 E-Expectations Trend Report on email, paid media, and social media…"
Jul 31
Charlie Holder joined DNI's group
Thumbnail

Cascade Server CMS

For folks who use (or are interested in) Hannon Hill's Cascade Server CMS productSee More
Jul 26
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Is your website in compliance with the new WCAG 2.1? Join our webcast to learn various accessibility guidelines, what’s new in 2.1, and more! http://bit.ly/2zhdcIt"
Jul 22
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"Even though GDPR has been in effect for over a year, many U.S. colleges and universities are still struggling with how best to implement the rules. We’re here to help. http://bit.ly/2YZZtRQ"
Jul 18
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"Does your college or university website meet the new WCAG 2.1 accessibility standards? http://bit.ly/2JBXD3s"
Jul 12
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Join us for our next webcast with Eric Turner from Mt. San Antonio College, who will share easy steps to make your website GDPR compliant. http://bit.ly/2zhdcIt"
Jul 10
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"It is always important to make a good first impression! Join Aaron Blau from Converge Consulting as he covers ways to make your web content attractive to your target audience and create an authentic brand message. http://bit.ly/2zhdcIt"
Jun 19
Jon Shaw posted a discussion

email obfuscation

Anyone using a javascript or php email obfuscation library that is effective for spam defense?See More
Jun 11
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Join us for our next webcast with Kelly Bostick from University of Arkansas who will provide some great tips on ways to ensure that all of your digital content is accessible. http://bit.ly/2zhdcIt"
Jun 6
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"Creating and producing website content is just the tip of the iceberg. In our latest white paper, learn how to manage that content to help your website reach its fullest marketing and recruiting potential. http://bit.ly/30WJ0PW"
May 30
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"A college or university website redesign is the most effective and cost-efficient way to attract and recruit new students. Download our ultimate guide to get started on your redesign today! http://bit.ly/30MmcSQ"
May 28
Cody Bryant is now a member of University Web Developers
May 20
Linda Faciana commented on Lynn Zawie's group OmniUpdate
"Join us for our next webcast with Rachael Frank from Gravity Switch to learn how to organize your content and messaging for a website redesign. http://bit.ly/2zhdcIt"
May 16
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"Capitalize on content by creating an editorial calendar for your college or university website. Here’s how: http://bit.ly/2WCauaY"
May 9
Sara Arnold commented on Lynn Zawie's group OmniUpdate
"A soft launch of your website redesign is well worth the extra time. Find out why. http://bit.ly/2LfeigX"
May 2

UWEBD has been in existence for more than 10 years and is the very best email discussion list on the Internet, in any industry, on any topic

About

© 2019   Created by Mark Greenfield.   Powered by

Badges  |  Report an Issue  |  Terms of Service