incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: Edit-related hash fields?
Date Wed, 04 Mar 2009 15:08:36 GMT
Ok -- that is pretty close to what I'd been able to reverse-engineer. :)

A few questions & observations:

> 1) An UTF-8 detector.  We put a single non-Latin1 character in the form to
> make sure the input is not mangled by some badly behaving robots or user
> clients. This used to be a major problem a few years back, and this solved
> all of those "hey, my edit destroyed all UTF-8 characters" -problems. It
> also turns out many of the older bots just assume a form is Latin1.

How big of an issue is this any more? Does this change if we require
accept-charset="UTF-8" on all our forms? Just wondering if we need to
carry this into 3.0.

> 2) An input field with a random name. This means that a bot will need to
> actually GET the form first and parse it out before it can send
> syntactically correct POSTs.  This is a LOT more effort than just simply
> looking at the fields once and crafting your auto-poster to conform.

This feels like a fairly standard anti-CSRF approach, although you
didn't call it that per se. I do think that this is something we
should have on *all* our forms, not just editing. I've pinged the
Stripes folks and think that we could probably solve the problem
there. See my comments here:

http://stripesframework.org/jira/browse/STS-363

I'd like to get your comments on the approach (within the Stripes JIRA
system, of course).

> 3) A hidden input field which is meant to catch those bots which do a GET
> and then randomly fill all fields with garbage.  This field MUST be empty
> when SpamFilter examines the contents of the POST. Since it's hidden with
> the use of CSS, the bot would need to understand CSS to bypass this one
> (and, the fieldname is also randomized in order to prevent someone from
> hardcoding the fact that it needs to be empty).

That is an interesting approach! It's a "honey pot" field,
essentially. That's a little less amenable to a framework-level fix,
unless we patch the Stripes FormTag class. If not, a simple custom Tag
class would probably be better than the inline scriptlet stuff we are
doing now.

Will muse on this a bit more...

Mime
View raw message