Actions

Proposals/Done/Anti-spam/Anti-spam Spec

From Mahara Wiki

< Proposals‎ | Done‎ | Anti-spam
Revision as of 17:43, 11 July 2020 by Anitsirk (talk | contribs) (Anitsirk moved page Developer Area/Specifications in Development/Done/Anti-spam/Anti-spam Spec to Proposals/Done/Anti-spam/Anti-spam Spec: Shorter navigation, not always technical)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Read Anti-spam first to see the idea generation that led to this specification.

General

  • A form will never be "quietly" rejected. An error message should always be displayed, possibly with some description of what step of validation failed. 100% of forms that appear to be accepted with no errors should be processed properly.

Contact Form

Changes to Form Structure

  • Existing CAPTCHA removed
  • The order of the "name" and "email" fields is chosen at random
  • All field names are MD5 hashes of the real field name (eg. 'firstname'), the client's IP address, the current time, and a server-side secret specified in config.php
  • A hidden field (with a fixed, unhashed field name) is added to store the timestamp used to generate the other field names
  • An invisible (not hidden) field is added to fool form-filling bots that don't actually visually render the page
  • An invisible submit button is added, and the order of the fake and real submit buttons is chosen at random

Form Validation

  • If the fake submit button was used, reject the form.
  • If the invisible field has any content, reject the form.
  • Read the timestamp field. If it is too far in the past (eg. more than a day old) or not old enough (eg. less than one second ago), reject the form.
  • Determine the IP of the client. Use it and the timestamp, along with the real field names and the secret, to recompute the hashed field names. If the recomputed hashes do not match the form's field names, then either the timestamp has been tampered with, or the client's IP has changed. In either case, reject the form. Otherwise, recover the form data.
  • Validate that the name field is NOT an email address. To be even more strict, make sure only letters and the occasional space, hyphen, or apostrophe are used.
  • Validate the email address. If it is an email address registered on the Mahara site, accept the form.
  • Validate the subject. If it contains newline characters or URLs, or is identical to the name or email fields, reject the form.
  • Check all URLs in the message body against uribl.com. If any are blacklisted, reject the form.
  • If the message body contains more than one URL, and any of them are greylisted, reject the form.

Registration Form

Same as Contact Form, except no validation of the message body, since there isn't one.