Open Bug 945476 Opened 12 years ago Updated 11 years ago

Add spam protection to /legal/fraud-report/

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: jpetto, Assigned: jpetto)

References

Details

(Whiteboard: [kb=1202623])

Attachments

(1 file)

TM Form spam examples.pdf
16.21 KB, text/pdf
Details
Other spam protection measures aren't cutting it on the recently ported /legal/fraud-report/ page. Adding ReCAPTCHA back to the page (it was present on the PHP version) should do the trick.
Assignee: nobody → jon
Whiteboard: [kb=1202623]
I thought we were trying to avoid captchas because a11y and other things? Have we tried all the things we did for the other forms? Honeypots and whatnot?
Yeah, the form has a honeypot and CSRF - apparently they are not enough. According to bug 905802, over 3000 spam (spams?) came through in one night. I'm not a fan of captcha's either, but it sounds like we need it here, at least until we figure out something better. Perhaps we should converse about additional back end protection - IP tracking, duplicate submissions, etc?
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/cf235d01518d7a449bd93c6d972db45b66a1d4bf Change fraud report input names to fight spam. Bug 945476. https://github.com/mozilla/bedrock/commit/ad87f0518037856702d1086548749b8b81a3cc83 Merge pull request #1490 from jpetto/bug-945476-fraud-report-spam-protection Change fraud report input names to fight spam. Bug 945476.
Joe & Liz - How has the spam been over the past few days? We pushed another (non-CAPTCHA) measure on Friday. Have you noticed any reduction since then?
I haven't seen any more spam
Great! Will mark this as complete, and keep the CAPTCHA code around just in case.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Jon - Just received 93 copies of the same email through this form.
Liz - Ack! Can you tell me in general how far apart the emails were? Just trying to figure out if it's being done by humans or robots.
They all came in at 7:52 or 7:53 PM
Yep, that's a bot. I'll re-open this bug and discuss with the team.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It happened again yesterday, 120 emails at the same time. I've also been getting about a dozen spam emails through the reporting form every day for the last few weeks, scattered throughout the day. I've also been meaning to ask if the form could open a bug rather than send an email, so I'm copying Glob and DKL. I don't want a bunch of spam bugs opened, so I was wondering if there's a way to solve both needs by setting some criteria that must be met in the way the form is completed before a bug would be opened. Is that possible? Also, does the form need to be redesigned in order to feed into a bug?
(In reply to Liz Compton [:liz] from comment #12) > I've also been meaning to ask if the form could open a bug rather than send > an email, so I'm copying Glob and DKL. my recommendation is to add ReCAPTCHA to the current form, and to update the backend code which currently sends an email to instead file a bug using bugzilla's APIs. we can't migrate this form directly to bugzilla because we require an account with a working email address, and your form has the email address as optional.
That sounds good to me. What are the next steps?
Since captcha's are so bad in regards to accessibility, UI, and usability, I think we should take one more stab at alternative measures. Josh & Paul - Any chance we can do something server side to restrict repeated submissions based on IP or cookie or something? What about using Akismet or a similar service? For the front-end, perhaps we could try picture or maths based validations?
I suggest making the honeypot field appear more legit so a bot is more likely to fill it. Make it a text field with an ordinary name like "Company" and (perhaps most importantly) move it to *before* the submit button. Right now the honeypot is a checkbox and it appears after the submit, so I'd wager this particular bot is hitting submit before it ever even sees the honeypot.
Good suggestion Craig. For accessibility reasons, we need to keep the label truthful - maybe something like "Enter your serial number if you are a machine. Required." We could also fairly easily randomize the id's on the form fields. Not sure how much this would help (spammers may refer to the name attribute), but I don't think it could hurt.
(In reply to Jon Petto [:jpetto] from comment #17) > Good suggestion Craig. For accessibility reasons, we need to keep the label > truthful - maybe something like "Enter your serial number if you are a > machine. Required." Correct, the label needs to be human-readable and explain that the field should be left blank, just for the edge case of someone disabling/overriding the CSS (the majority of screen readers don't read content hidden with display:none). It could be as simple as "Leave this field empty." > We could also fairly easily randomize the id's on the form fields. Not sure > how much this would help (spammers may refer to the name attribute), but I > don't think it could hurt. Yeah, they pay more attention to names than IDs. The trick is to make the name something a comment form is likely to include: company, city, age, that sort of thing. Ironically, bots fill those in to appear more human so we can use their automated stupidity against them. There also might be some server-side things we can do. I'm not sure what measures we're already taking with mod_security and such, but we might be able to block user-agents that send malformed request headers. Bad Behavior is a bot-blocking plugin for WordPress and Mediawiki that does a good job with this. It's PHP but we might be able to do something similar in Python http://bad-behavior.ioerror.us/. And we should look into using Akismet.
Issued a PR to improve the honeypot based on suggestions above: https://github.com/mozilla/bedrock/pull/1746/ > I've also been meaning to ask if the form could open a bug rather than send > an email, so I'm copying Glob and DKL. I don't want a bunch of spam bugs > opened, so I was wondering if there's a way to solve both needs by setting > some criteria that must be met in the way the form is completed before a bug > would be opened. Is that possible? Also, does the form need to be redesigned > in order to feed into a bug? I don't think it's a good idea to allow a public facing form to generate bugs. Even if spam wasn't an issue (which it likely always will be - some spammers just fill out forms by hand), the probability of low quality reports and duplicates would be too high.
Blocks: 963816
+1 for Akismet. Honeypot fields are nice, but aren't going to be nearly as effective. The Bad Behavior WP plugin that :craigcook mentioned has a really interesting approach, but porting it from PHP would be a rather large undertaking, and I believe our engineering resources would be better spent elsewhere.
If it isn't a good idea to have these reports open bugs automatically, any suggestions on changes to the form or other techniques to make it as easy and quick as possible to create bugs from the info contained in the ones worth pursuing?
We've decided as a team not to use recaptcha so editing the summary line. We are looking at implementing Kismet instead and I will update the bug with more info.
Summary: Add ReCAPTCHA to /legal/fraud-report/ → Add spam protection to /legal/fraud-report/
Akismet isn't in scope for this launch. Once the Honeypot improvements in the PR are r+ we can resolve the bug and push the Privacy Center updates. We're investigating Akismet in another bug.
fixed on https://www-demo2.allizom.org/en-US/legal/fraud-report/?submitted=True
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Keywords: qawanted
Resolution: --- → FIXED
Could you explain the fix to me? Thanks.
Liz - In this update, we renamed the honeypot field to something a bit more sneaky and placed it near other similar fields in the form. The hope is that the bots will fall into the trap more often when it looks more like a legitimate field.
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/b0b65e4100816288125716917c44202970ae1d49 Improve honeypot spam protection. Bug 945476. https://github.com/mozilla/bedrock/commit/7590a3127f4a58434ad7f8d0abe938d9bd3bf65d Merge pull request #1746 from jpetto/bug-945476-fraud-report-spam-protection Improve honeypot spam protection. Bug 945476.
Hi again. Attached are a few samples of emails coming in from this form. I'm getting 10-20 of these a day and have been for a couple of months at least. Is there anything that can be done to stop them?
OK, looks like the honeypot isn't working. Jon, do you have availability to investigate?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I think the first step is to work with IT to see why internal mail filtering isn't flagging email with this type of spam-y content. If the internal filter is doing all it can, we should then figure out implementation of a spam filtering service (like Akismet). Mike - Do you know who we should cc in IT to check on the former? A third option would be a captcha-like question system (e.g. "What is seven minus 3?"). However, this should be a lower priority, as it would do very little to stop human spammers.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: