[
http://www.stripesframework.org/jira/browse/STS-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11676#action_11676
]
Andrew Jaquith commented on STS-363:
------------------------------------
John, good comments. Your approach sounds good too. In my implementation, I
chose to throw a checked exception rather than hard-code a forward to an error
page. The exception could be then be caught by the various Stripes exception
classes and forwarded however the deployer wants. This is probably a little
more portable than what you did, but only because I want this patch included in
the core. :)
FYI, my proposed "ticketing" system for forms won't help with cross-site
scripting (XSS) per se. The best defense against XSS is to (1) ruthlessly
filter input (remove/prohibit angle brackets etc) and (2) sanitize/escape all
output of user-submitted content. The JSTP <c:out> tag does this by default
automatically, and should be used in preference to plain EL (${}) expressions.
The OWASP folks have a great guide on how to do this.
> Flow Control Token to prevent XSRF/double-posting
> -------------------------------------------------
>
> Key: STS-363
> URL: http://www.stripesframework.org/jira/browse/STS-363
> Project: Stripes
> Issue Type: New Feature
> Components: Context Management, Tag Library
> Reporter: Sylvan von Stuppe
> Priority: Minor
> Attachments: FormTickets.patch, FormTickets2.patch
>
>
> I would love to have a built-in feature for generating a random token,
> putting this token into the user's session, then be able to have the same
> token as a hidden form value on subsequent pages. When a user submits a
> page, the token the send is checked against the one in the session (possibly
> as part of the @Validate annotation?) and if they don't match, the user is
> sent to a different page. If they do match, the action continues.
> I attempted to do this as part of a BaseActionBean class, but it quickly fell
> apart because the default binding is for the form to be populated by what the
> user submitted, not what's in the bean. So the first request would work
> because the user didn't submit anything, the attribute is gotten from the
> bean (which would generate the new token, set it in the session, and return
> it), and was presented on the form. But on subsequent requests, the value
> came from what the user submitted (the old token), rather than from the bean.
> So I ended up having to use a vanilla <input> tag with ${} to get the value
> out of the request scope.
> I don't know of the most "Stripes friendly" way to implement this, but I
> suspect it would require changes to the ActionBeanContext and certainly the
> tag libraries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
