So, a quick update on this. The anti-CSRF feature (#2) seemed important enough that it warranted me writing a patch for Stripes. That's what I've done, and I'm awaiting to hear from the Stripes team to see if it warrants inclusion in the main branch.
Basically, what the feature does is require users to access the "display JSP" before submitting the POST. It does this by causing the stripes:form tag to generate a unique "ticket" param that is later required to access an event handler method. Methods can be marked as protected simply by annotating them with @TicketRequired (with an optional "timeout" parameter). FYI the ticket parameter name is not actually randomized; it's overkill because the value isn't predictable. The patch is here: http://stripesframework.org/jira/browse/STS-363 So, if it's accepted to the trunk we will get this feature "for free." If not, I'll pull it back into JSPWiki. As for the other items (#1 and #3), these are things I'd like to reimplement, but in a slightly different way. I agree that a tag would be good, although I prefer "wiki:spamProtect." Similar to how we do it now, the tag would generate the UTF-8 "canary" field (mangled return value means UTF-8 not supported), plus the honeypot spam trap field. The canary param can be a fixed field name; the spam-trap param still be random. Where I think we could do things a little differently is how we manage stuff that gets stashed in the session. We could re-use the Ticket scheme I developed for Stripes, or do something like what Stripes does, which is to write out an encrypted parameter with the name of the spam-trap param as the payload. The latter is probably the better approach. Verification would be via an Interceptor, and we could simply state that if the target ActionBean event handler method had a @TicketRequired annotation, we should *always* do the spam-check thing. Andrew On Wed, Mar 4, 2009 at 5:33 PM, Janne Jalkanen <[email protected]> wrote: >> 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. > > The problem is that badly behaving clients will behave badly regardless of > what accept-charset says. So I'd rather keep it. There are still plenty of > broken clients out there. > >>> 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. > > No, 'cos I thought about it before I heard about CSRF ;-) > >>> 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. > > Well, we could have a simple <wiki:SpamFilterFields /> in there somewhere > which could insert all of these. > > /Janne >
