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 Tue, 10 Mar 2009 07:22:21 GMT
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 <Janne.Jalkanen@ecyrd.com> 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
>

Mime
View raw message