You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by David Geary <sa...@tri-lakesonline.net> on 2000/12/23 00:19:48 UTC
Proposal: Tokens and Events Guard Against Form Resubmission
ABSTRACT
It's easy for Web application users to inadvertently resubmit forms with
bookmarks or the reload and back buttons. Because of this potential for
mischief, web applications must guard against resubmission of sensitive
forms. This document proposes using the delegation event model and
tokens to restrict access to sensitive pages.
Note: This proposal depends on action events as proposed in 'Proposal:
Retrofit Struts with the Delegation Event Model'.
CREDITS
'Command Token Implementation', posted to struts-dev by Robert Leland
Struts Web Application Safety' on struts-dev, by Craig McClanahan
'What about This Model?', posted to struts-user by Dan Cancro
Web Development with JavaServer Pages, by Kolb and Fields, p 270
INTRODUCTION
Web browsers were designed for browsing the Web, not for applications.
Some browser features, such as the back button, reload button, and
bookmarks, are difficult for web applications to deal with because they
disrupt the normal flow of an application. This proposal shows how to
trap those browser features in Struts using the delegation event model
and tokens.
THE PROBLEM
Consider the following sequence of actions, as Timothy creates a new
account. First, Timothy tries to login, but since he does not have an
account, he's forwarded to the Login Failed page:
[Image]
Figure 1. The Login Failed Page
Timothy clicks on the open new account link and is forwarded to this
page:
[Image]
Figure 2. The Open New Account Page
Timothy fills in the form shown in Figure 2, clicks the create account
button, and is forwarded to the login page:
[Image]
Figure 3. The Login Page
At this point, Timothy's account has been created and he can login, but
what if he reloads the page instead? Or what if he hits the back button,
and then clicks on the create account button without changing the form's
data? In both cases, a duplicate request will be sent to the
new-account-action. That action might detect the duplicate, but it's a
lot to ask all actions to test for duplicate submissions. Let's see how
Struts can trap such illicit access at a higher level.
TRAPPING ILLICIT ACCESS WITH STRUTS
WHAT IT DOES
Guard against sensitive form resubmission. If a sensitive form is
resubmitted, Struts throws an exception.
HOW IT'S IMPLEMENTED
Trapping illicit access is implemented in this proposal with tokens, as
described by Fields and Kolb (see credits). Here's how it works: